Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Databases in 2025: A Year in Review

cs.cmu.edu

Post reply on HN
Print view View original

81–90 of 196 posts

Re: Databases in 2025: A Year in Review

#81

Post by sanderjd »

qcnguy wrote: post #61
codeulike wrote: post #59

Barely any mention of Oracle or MS Sql Server, commonly reckoned to be #1 and #3 most used databases in the world https://db-engines.com/en/ranking

Oracle is mentioned at the start, where he proclaims the "dominance" of Postgres and then admits its newest features have been in Oracle for nearly a quarter of a century already. The dominance he's talking about is only about how many startups raise how many millions from investors, not anything technical. And then of course at the end he has a whole section about Larry Ellison, like always.

Isn't it because it's about news, as in what's changing, rather than being about what's staying the same? He's a researcher, so his interests are always going to be more oriented toward new systems and new companies more than the big dominant systems.

Re: Databases in 2025: A Year in Review

#82

Post by nlittlepoole »

sanderjd wrote: post #69
delaminator wrote: post #10

Earlier quoted context omitted.

From my perspective, everything's DuckDB. Single file per database, Multiple ingestion formats, full text search, S3 support, Parquet file support, columnar storage. fully typed. WASM version for full SQL in JavaScript.

This is a funny thread to me because my frustration is at the intersection of your comments: I keep wanting sqlite for writes (and lookups) and duckdb for reads. Are you aware of anything that works like this?

DuckDB can read/write SQLite files via extension. So you can do that now with DuckDB as is.

https://duckdb.org/docs/stable/core_extensions/sqlite

Re: Databases in 2025: A Year in Review

#83

Post by SJMG »

odie5533 wrote: post #13
TekMol wrote: post #9

From my perspective on databases, two trends continued in 2025: 1: Moving everything to SQLite 2: Using mostly JSON fields Both started already a few years back and accelerated in 2025. SQLite is just so nice and easy to deal with, with its no-daemon, one-file-per-db and one-type-per value approach. And the JSON arrow functions make it a pleasure to work with flexible JSON data.

For as much talk as I see about SQLite, are people actually using it or does it just have good marketers?

It's the standard for mobile. That said, in server-side enterprise computing, I know no one who uses it. I'm sure there are applications, but in this domain you'd need a good justification for not following standard patterns.

I have used DuckDB on an application server because it computes aggregations lightning fast which saved this app from needing caching, background services and all the invalidation and failure modes that come with those two.

Re: Databases in 2025: A Year in Review

#84

Post by em500 »

andrewinardeer wrote: post #11
TekMol wrote: post #9

From my perspective on databases, two trends continued in 2025: 1: Moving everything to SQLite 2: Using mostly JSON fields Both started already a few years back and accelerated in 2025. SQLite is just so nice and easy to deal with, with its no-daemon, one-file-per-db and one-type-per value approach. And the JSON arrow functions make it a pleasure to work with flexible JSON data.

Pardon my ignorance, yet wasn't the prevailing thought a few years ago that you would never use SQLite in production? Has that school of thought changed?

"Production" can mean many different things to different people. It's very widely used as a backend strutured file format in Android and iOS/macOS (e.g. for appls like Notes, Photos). Is that "production"? It's not widely used and largely inappropriate for applications with many concurrent writes.

Sqlite docs has a good overview of appropriate and inappropriate uses: https://sqlite.org/whentouse.html It's best to start with Section 2 "Situations Where A Client/Server RDBMS May Work Better"

Re: Databases in 2025: A Year in Review

#85

Post by sanderjd »

pjmlp wrote: post #57
sandos wrote: post #36

Earlier quoted context omitted.

This sounds like a flashback to J2EE. Which I know is still alive and well. Banks, insurance companies and the tax agency do not much care for fancy new stuff, but that it works.

Yep, Fortune 500 enterprise consulting, boring technology that pays the bills. Java, .NET, C++, nodejs, Sitecore, Adobe Experience Manager, Optimizely, SAP, Dynamics, headless CMSes,...

Never felt so old, seeing nodejs in a list of old boring stuff.

Re: Databases in 2025: A Year in Review

#86

Post by TekMol »

DrBazza wrote: post #74
TekMol wrote: post #9

From my perspective on databases, two trends continued in 2025: 1: Moving everything to SQLite 2: Using mostly JSON fields Both started already a few years back and accelerated in 2025. SQLite is just so nice and easy to deal with, with its no-daemon, one-file-per-db and one-type-per value approach. And the JSON arrow functions make it a pleasure to work with flexible JSON data.

From my perspective - do you even need a database? SQLite is kind-of the middle ground between a full fat database, and 'writing your own object storage'. To put it another way, it provides 'regularised' object access API, rather than, say, a variant of types in a vector that you use filter or map over.

If I would write my own data storage I would re-implement SQLite. Why would I want to do that?

Re: Databases in 2025: A Year in Review

#87

Post by sanderjd »

nlittlepoole wrote: post #82
sanderjd wrote: post #69

Earlier quoted context omitted.

This is a funny thread to me because my frustration is at the intersection of your comments: I keep wanting sqlite for writes (and lookups) and duckdb for reads. Are you aware of anything that works like this?

DuckDB can read/write SQLite files via extension. So you can do that now with DuckDB as is. https://duckdb.org/docs/stable/core_extensions/sqlite

My understanding is that this is still too slow for quick inserts, because duckdb (like all columnar stores) is designed for batches.

Re: Databases in 2025: A Year in Review

#88

Post by sanderjd »

SchwKatze wrote: post #75
sanderjd wrote: post #69

Earlier quoted context omitted.

This is a funny thread to me because my frustration is at the intersection of your comments: I keep wanting sqlite for writes (and lookups) and duckdb for reads. Are you aware of anything that works like this?

I think you could build an ETL-ish workflow where you use SQLite for OLTP and DuckDB for OLAP, but I suppose it's very workload dependent, there are several tradeoffs here.

Right. This is what I want, but transparently to the client. It seems fairly straightforward, but I keep looking for an existing implementation of it and haven't found one yet.

Re: Databases in 2025: A Year in Review

#89

Post by divan »

> Acquisitions ... Gel → Vercel

is a bit misleading. Gel (formerly EdgeDB) is sunsetting it's development. (extremely talented) Team joins Vercel to work on other stuff.

That was a hard hit for me in December. I loved working with EdgeQL so much.

Re: Databases in 2025: A Year in Review

#90

Post by theanonymousone »

sanderjd wrote: post #87
nlittlepoole wrote: post #82

Earlier quoted context omitted.

DuckDB can read/write SQLite files via extension. So you can do that now with DuckDB as is. https://duckdb.org/docs/stable/core_extensions/sqlite

My understanding is that this is still too slow for quick inserts, because duckdb (like all columnar stores) is designed for batches.

The way I understood it, you can do your inserts with SQLite "proper", and simultaneously use DuckDB for analytics (aka read-only).
Post reply on HN