Our great database migration

&gt; bundling an 80MB+ SQLite file to our codebase slowed down the entire Github repository and hindered us from considering more robust hosting platforms<p>This seems like a decent reason to stop committing the database to GitHub, but not a reason to move off SQLite.<p>If you have a small, read-only workload, SQLite is very hard to beat. You can embed it ~everywhere without any network latency.<p>I&#x27;m not sure why they wouldn&#x27;t just switch to uploading it to S3. Heck, if you really want a vendor involved that&#x27;s basically what <a href="https:&#x2F;&#x2F;turso.tech&#x2F;" rel="nofollow">https:&#x2F;&#x2F;turso.tech&#x2F;</a> has productized.

&quot;Overall, this migration proved to be a massive success&quot; but their metrics shows this migration resulted in, on average, slower response times. Wouldn&#x27;t this suggest the migration was not successful. Postgres can be insanely fast, and given the volume of data this post suggests, it baffles me that the performance is so bad.

What a bizarre article… performance ended up being worse, how can that be considered a resounding success? Doesn’t seem like it’s a slam dunk case for using neon

Lots of comments about the drop in performance. No matter how well you tune network PostgreSQL it&#x27;s going to have trouble coming close to the performance you can get from a read-only 80MB SQLite file.<p>They didn&#x27;t make this change for performance reasons.

If most queries take ~ 1s on a relatively small 80MB dataset, then it sounds to me like they really needed to run EXPLAIN on their most complex queries and then tune their indexes to match.<p>They could have probably stayed with SQLite, in fact, because most likely it&#x27;s a serious indexing problem, and then found a better way to distribute the 80MB file rather than committing it to Github. (Although there are worse ideas, esp with LFS)

I don&#x27;t see any mention of the data size or volume of transactions? Also, your API response times were worse after you finished and optimized, and that&#x27;s a success? or you&#x27;re comparing historical SQLite vs new PostgreSQL? I kinda see this more as a rewrite than a database migration (which I&#x27;m going through now from SQL Server to PostgreSQL)

&gt; 79.15% of our pricing operations averaged 1 second or less response time<p>These numbers are thrown out there like they&#x27;re supposed to be impressive. They must be doing some really complex stuff to justify that. For a web server to have a p79 of 1 second is generally terrible.<p>&gt; 79.01% to average 2 seconds or less<p>And after the migration it gets FAR worse.<p>I get that it&#x27;s a finance product, but from what they wrote it doesn&#x27;t seem like a large dataset. How is this the best performance they&#x27;re getting?<p>Also a migration where your p79 (p-anything) doubled is a gigantic failure in my books.<p>I guess latency really mustn&#x27;t be critical to their product

&gt; Ensure database is in same region as application server<p>People tend to forget that using The Cloud (tm) still means that there&#x27;s copper between a database server and an application server and physics still exist.

If it is a read-only database, I don&#x27;t fully understand where all the latency is coming from. Is it complex SQL queries?

This post is 100% marketing “oh we had so few customers SQLite was great but now we need Postgres” ignore it

The latency before&#x2F;after histograms unfortunately use different scales, but it appears that eg the under-200ms bucket is only a few percentage points smaller after the change, maybe 38 before and 33 after.<p>What I&#x27;m curious about is whether Neon can run pg locally on the app server. The company&#x27;s SaaS model doesn&#x27;t seem to support that, but it looks technically doable, particularly with a read-only workload.

If starting off with Elixir and Postgres from the get-go, all this could have been avoided - including the async pains. Said another way: don’t write you backend in JS and just use Postgres.

Where is the cto or senior technical leader in this? The team seems to be trying hard and keeping the lights on, but honestly there are several red flags here. I’m especially skeptical about the painful and complex manual process that is now 1-click. I want to hope they succeed, but this sounds awfully naive.

PSA: If you&#x27;re running a business and some databases store vital customer or financial data, consider EnterpriseDB (EDB). It funds Postgres and can be used almost like Oracle DBMS. And definitely send encrypted differential backups to Tarsnap for really important data.

Shepherd raised $13.5M earlier this year. Imagine being an investor in this company and seeing this post. They seriously wrote a lengthy post publicizing their struggles with an 80MB database and running some queries. The entire technical team at this company needs to be jettisoned.<p>These are the sort of technical struggles a high school student learning programming encounters. Not a well-funded series A startup. This is absolutely bonkers.

I wonder if DuckDB with parquet storage on S3 (or equivalent) would have been a nice drop-in replacement. Plus DuckDB probably would have done quite well in the ETL pipeline.

Not to be negative but it seems like many tech posts like this are thinly veiled hiring &#x2F; recruitment blog posts .

Does the sqlite java lib bundle support for many platforms which jacks up the app size?

&gt; Furthermore, bundling an 80MB+ SQLite file to our codebase slowed down the entire Github repository and hindered us from considering more robust hosting platforms.<p>It&#x27;s... an 80MB database. It couldn&#x27;t be smaller. There are local apps that have DBs bigger than that. There is no scale issue here.<p>And... it&#x27;s committed to GitHub instead of just living somewhere. And they switched to Neon.<p>To me, this screams &quot;we don&#x27;t know backend and we refuse to learn&quot;.<p>To their credit, I will say this: They clearly were in a situation like: &quot;we have no backend, we have nowhere to store a DB, but we need to store this data, what do we do?&quot; and someone came up with &quot;store it in git and that way it&#x27;s deployed and available to the app&quot;. That&#x27;s... clever. Even if terrible.

It&#x27;s more complicated and slower but it&#x27;s still a &quot;success&quot;. LOL.

You. Were. Running. An. Insurance. Company. On. SQLite?<p>What?<p>What possessed them?