Use local SQLite database

[ScriptRaccoon]

This PR implements a fundamental change to CatDat's infrastructure.

Since CatDat only reads from the database at runtime, it should be possible to use a local database file for its queries (both live and during prerendering) instead of a remote database (currently hosted on Turso). Netlify's file system is ephemeral, so storing a database there is generally not recommended, but for read-only use it appears to be OK.

This should provide a major performance boost, especially for the search and comparison pages, since database queries now have almost no latency. All other pages are prerendered anyway. I also expect a significant reduction in complexity, since the CatDat database can be removed from Turso* and the deployment workflow only needs to build the local file (which it already did). This should also speed up deployment pipelines. Furthermore, migrations are not required anymore since the database can be recreated from scratch anytime.

(The second database, app.db, which stores page visits and user submissions, requires write access and will remain on Turso.)

I went for the better-sqlite3 package. Its queries are synchronous, so the query helper function is no longer async. This is the only change required in the load functions of the Svelte files. More adjustments were needed in the deduction scripts. The package node:sqlite is still considered experimental, which is why I don't want to use it for now.

*Hence, the environment variables CATDAT_DB_URL and CATDAT_DB_AUTH_TOKEN can be removed.

Performance comparison

Search

The search feels much faster now. The following shortened Netlify logs demonstrate this. I ran the same four search queries in each case. The reported time is the total request duration.

Before

INFO   ?satisfied=cartesian_closed&unsatisfied=elementary_topos
Duration: 465.65 ms
INFO   ?satisfied=Grothendieck_abelian&unsatisfied=accessible
Duration: 303.6 ms	
INFO   ?satisfied=finite%7ECauchy_complete&unsatisfied=cofiltered_limits
Duration: 320.35 ms
INFO   ?satisfied=complete%7Ecocomplete&unsatisfied=locally_presentable%7Eextensive
Duration: 534.78 ms

After

INFO   ?satisfied=cartesian_closed&unsatisfied=elementary_topos
Duration: 212.12 ms
INFO   ?satisfied=Grothendieck_abelian&unsatisfied=accessible
Duration: 143.47 ms
INFO   ?satisfied=finite%7ECauchy_complete&unsatisfied=cofiltered_limits
Duration: 10.8 ms
INFO   ?satisfied=complete%7Ecocomplete&unsatisfied=locally_presentable%7Eextensive
Duration: 21.11 ms

Comparison

The comparison feels much faster now. Again, this is confirmed by the Netlify logs. I ran the same two comparison queries in each case. The reported time is the total request duration.

Before

INFO   Mon/CMon/Grp/Ab
Duration: 340.43 ms
INFO   Set*/Top*
Duration: 338.19 ms

After

INFO   Mon/CMon/Grp/Ab
Duration: 53.89 ms
INFO   Set*/Top*
Duration: 36.09 ms

Deployment

This measures the time required for the preview deployment pipeline to complete. The production pipeline is likely similar.

Before

~3–4 min

After

~1 min

Lighthouse Tests

Performance results from Lighthouse were inconclusive. The main current bottleneck is loading KaTeX.