I will give you a possible solution, although I´m sure there are plenty similar questions out there and, as suggested in the comments, you should have come up with some details about your data and software...
Also, listen to @Vince and choose a projection suitable for distance measurements for your area of interest, maybe using
geography type even, and maybe update your geometry column (or create an additional geometry/geography column) in advance. I will not provide any reprojection in my solution and use the column identifiers as per your question; alter the commands accordingly if you want to use different geometry/geography columns.
First off, make sure you have your tables' geometry indexed properly, otherwise this will probably run until the end of time:
CREATE INDEX schema1.data1_gix ON schema1.data1 USING GIST (geom);
CREATE INDEX schema2.data2_gix ON schema2.data2 USING GIST (geometry);
To update the internal table statistics for the query plan estimation to take the indexes properly into account, run:
VACUUM ANALYZE schema1.data1;
VACUUM ANALYZE schema2.data2;
Then, to actually find the nearest line to your points, you can use the
LATERAL JOIN, executing a subquery for each consecutive row in the main query; per definition this will scan the entire table defined in the subquery once for each row in the table defined in the main query ('eternity' is just a small scale if you do this without indexes...)
To actually use the index efficiently, use the
<-> operator instead of
ST_Distance() in the
ORDER BY statement (the docs on
<-> does say it's index search will kick in if also used with a constant only; in this case, I guess, each row of the main query given to the
LATERAL JOIN as it´s parameter is considered as a constant, thus it will run an index scan on the table in the subquery):
FROM schema1.data1 AS br
JOIN LATERAL (
St_Distance(at.geometry, br.geom) AS dist
FROM schema2.data2 AS at
ORDER BY br.geom <-> at.geometry
) AS subquery
I used your identifiers as per your question in numerical order; make sure the table in the subquery is the one with the lines.
This query needs around 6 seconds to execute, with 150.000 rows in the main query's table and 75.000 rows is the subquery's table on my mid tech machine.