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

Show HN: Embed an SQLite database in your PostgreSQL table

github.com

Post reply on HN
Print view View original

31–40 of 116 posts

Re: Show HN: Embed an SQLite database in your PostgreSQL table

#31

Post by Zambyte »

TekMol wrote: post #27

Are there still reasons to use PostgreSQL? I like the simplicity of SQLite's "a file is all you need" approach so much, that I started to converge all my projects to SQLite. So far, I have not come across any roadblocks. Can anyone think of a use case where PostgreSQL is better suited than SQLite?

When your application scales beyond one machine that needs access to the same database, PostgreSQL becomes an obviously better choice than SQLite. Until that point, SQLite is a fine, and honestly underrated choice.

DuckDB is another option worth considering.

Re: Show HN: Embed an SQLite database in your PostgreSQL table

#33

Post by emseetech »

TekMol wrote: post #27

Are there still reasons to use PostgreSQL? I like the simplicity of SQLite's "a file is all you need" approach so much, that I started to converge all my projects to SQLite. So far, I have not come across any roadblocks. Can anyone think of a use case where PostgreSQL is better suited than SQLite?

The biggest one is redundancy. Architecting with Read replicas is much easier with Postgres than Sqlite because of it's server model.

Sqlite on the server is a fantastic starter database. Dead simple to set up, highly performant and scales way higher (vertically) than anyone gives it credit for.

But there certainly is a point you'll have to scale out instead of up, and while there are some great solutions for that (rqlite, litefs, dqlite, marmot) it's not inherent to Sqlite's design.

Re: Show HN: Embed an SQLite database in your PostgreSQL table

#34

Post by 2codr2pro2max »

TekMol wrote: post #27

Are there still reasons to use PostgreSQL? I like the simplicity of SQLite's "a file is all you need" approach so much, that I started to converge all my projects to SQLite. So far, I have not come across any roadblocks. Can anyone think of a use case where PostgreSQL is better suited than SQLite?

Jeebus i keep forgetting how many of you are bootcamp noobs here

Re: Show HN: Embed an SQLite database in your PostgreSQL table

#36

Post by emseetech »

2codr2pro2max wrote: post #34
TekMol wrote: post #27

Are there still reasons to use PostgreSQL? I like the simplicity of SQLite's "a file is all you need" approach so much, that I started to converge all my projects to SQLite. So far, I have not come across any roadblocks. Can anyone think of a use case where PostgreSQL is better suited than SQLite?

Jeebus i keep forgetting how many of you are bootcamp noobs here

Maybe so but this isn't helpful.

Re: Show HN: Embed an SQLite database in your PostgreSQL table

#38

Post by TekMol »

Zambyte wrote: post #31
TekMol wrote: post #27

Are there still reasons to use PostgreSQL? I like the simplicity of SQLite's "a file is all you need" approach so much, that I started to converge all my projects to SQLite. So far, I have not come across any roadblocks. Can anyone think of a use case where PostgreSQL is better suited than SQLite?

When your application scales beyond one machine that needs access to the same database, PostgreSQL becomes an obviously better choice than SQLite. Until that point, SQLite is a fine, and honestly underrated choice. DuckDB is another option worth considering.

Should the concept of "machines" really be a concern of the DB layer?

SQLite already allows multiple connections, so putting it on a server and adding a program that talks a network protocol and proxies the queries to the DB sounds more logical to me?

Re: Show HN: Embed an SQLite database in your PostgreSQL table

#39

Post by evandrofisico »

TekMol wrote: post #38
Zambyte wrote: post #31

Earlier quoted context omitted.

When your application scales beyond one machine that needs access to the same database, PostgreSQL becomes an obviously better choice than SQLite. Until that point, SQLite is a fine, and honestly underrated choice. DuckDB is another option worth considering.

Should the concept of "machines" really be a concern of the DB layer? SQLite already allows multiple connections, so putting it on a server and adding a program that talks a network protocol and proxies the queries to the DB sounds more logical to me?

And after all of that you basically have something that looks like postgres or mysql.

Re: Show HN: Embed an SQLite database in your PostgreSQL table

#40

Post by TekMol »

emseetech wrote: post #33
TekMol wrote: post #27

Are there still reasons to use PostgreSQL? I like the simplicity of SQLite's "a file is all you need" approach so much, that I started to converge all my projects to SQLite. So far, I have not come across any roadblocks. Can anyone think of a use case where PostgreSQL is better suited than SQLite?

The biggest one is redundancy. Architecting with Read replicas is much easier with Postgres than Sqlite because of it's server model. Sqlite on the server is a fantastic starter database. Dead simple to set up, highly performant and scales way higher (vertically) than anyone gives it credit for. But there certainly is a point you'll have to scale out instead of up, and while there are some great solutions for that (r…

Should replication really be a concern of the DB layer?

Replication means writing queries which alter the data to multiple machines, right?

Shouldn't that be done by a software one level up? Which takes in the queries via some network protocol and then sends them to all machines.

That would sound more logical to me.

Post reply on HN