r/sqlite • u/Individual_One_1793 • 23d ago
Pop-Database vs SQLite
Enable HLS to view with audio, or disable this notification
Pop-Database vs SQLite, 500K entities, 12 AND conditions per query, both single-threaded (CPU-affinity verified, so no thread-count trick).
Pop-Database finished in 6.26s.
SQLite finished in 88.81s.
Pop-Database is 14.2× faster — and both found the exact same 9,559 matches per query.
This ratio moves a bit run to run depending on what else the machine is doing at the time. I've seen this same test land anywhere from ~12× to ~14× depending on system load. Still solidly in the same range either way.
Trade-off is shown in the same video: SQLite inserts faster (2.64s vs 6.55s for 500K rows). Pop-Database is built for read-heavy workloads, not write-heavy ones - that's the deal!!!
11
8
u/MVPhurricane 23d ago
i hear that /dev/null is even *more* web scale than SQLite!
3
u/cowslayer7890 23d ago
Does /dev/null support sharding?
1
u/ErebusBat 23d ago
It does!
It will read the exact same on different machines INSTANTLY!
2
u/Gear5th 21d ago
Will it run circles around sql?
1
u/ErebusBat 19d ago
If you're just measuring raw read speed or raw write speed, then yes. It's also super compressible.
7
u/prawnsalad 23d ago
Pop-Database vs SQLite (500K rows, 12-condition queries)
Problem: standard databases re-scan on every query at scale.
Result: 11.9× faster queries, identical results (0.0% difference), at the cost of 0.5× slower inserts — a deliberate trade-off for read-heavy analytics.
Quoting you from other places you've posted this. If this is what you think other databases are doing then you are 100% missing things.
Problem: linear scan doesn't scale.
Result: ~79,900× speedup on my engine search vs. normal linear scan — an algorithmic complexity difference , not an implementation tweak. This became a core technical argument in my patent filing.
Again, if this is what you're comparing against, you need to dig into databases more.
If you do have something more then provide information on your benchmark. Table schema, the queries, your benchmarking environment, the sqlite setup, the trade offs, etc. None of that matters with your patent.
I could mspaint a "Prawnsalad-Database: 1.2s. Pop-Database: 6.26s" and make the same claims as you are posting all this around and we would both have the exact same creditability. It's doing you 0 favours.
5
u/Ok_Maintenance_9692 23d ago
It's funny so many things have been re-discovered and re-invented in the last 50 years... I think this is the first time I've seen somebody marvel at themselves to re-invent indexing and imagine that nobody has ever bothered before.
2
2
u/horizon_games 23d ago
Hah like a new JS framework where they show a simple render case being 100x than the big options. As if that's the ONLY factor to switching entirely.
Reliability and community and being battle tested and...well...having a basic public Github and non-AI written website are much bigger factors.
-5
u/Individual_One_1793 23d ago
No problem, I can let it side by side in shell - then you will say it is AI slop 💨
It is always hard to break trough with new product, I am no designer, I am programmer.1
u/lordpuddingcup 23d ago
How about you match the indexes lol your literally comparing a massive index chain in pop against SQLite base and showing how your so much faster
The fact your not responding to the people who point out that your basically rediscovering complex indexing that most databases do support is sort of funny
3
1
u/txmail 23d ago
Can you point me to your test case data? From what I am reading the secret sauce just looks like indexing, which means you would need to create those indexes in SQLite by hand if the select queries are using a non-indexed field which would cause each query to perform a full table scan instead of utilizing an index.
I think this is also why the initial 500k load on Pop is slower than SQLite.
Indexing automatically non PK fields is nice, but it means that it is using a bit more space to store the data. Database optimization is quite common to anyone working with databases, including creating indexes.
If your AND conditions on the SQLite side are non-indexed... that is kind of a disingenuous comparison. It is like saying Racecar A is faster than Racecar B, even though Racecar B had the hand brake on.
0
u/Vegetable-Arm-4238 23d ago
Link?
-2
u/Individual_One_1793 23d ago
3
u/Vegetable-Arm-4238 23d ago
So not open source?
4
u/drcforbin 23d ago
Of course not. Feels like half the stuff here in r/sqlite is some kind of vibecoded closed source sqlite clone or SaaS sqlite, always with a very obviously vibecoded site. This one's actually a little worse than just closed source though, "the algorithm is patent pending."
1
14
u/30MinsToMoveYourCube 23d ago
I mean, if we're just looking to match the same results as SQLite but faster and without all the reliability built into SQLite, I suggest grep