Sqlite is a better fit for most applications. enterprises prefer big bulky sql databases with lots of security features...

sqlite is a better fit for most applications. enterprises prefer big bulky sql databases with lots of security features, but for most startups and hackers and so on, sqlite is a better option. For horizontal scaling, neither is a good option. You are better off using mongodb and other nosql options.

Attached: download.png (326x154, 8.9K)

Other urls found in this thread:

stackoverflow.com/questions/16916633/if-postgresql-count-is-always-slow-how-to-paginate-complex-queries
sqlite.org/lang_altertable.html#making_other_kinds_of_table_schema_changes
twitter.com/AnonBabble

>sqlite is a better fit for most applications
No, SQLite is a toy database.

pretty much every big tech company actually uses scaled out postgres. nosql databases are a bad joke

>big bulky sql databases
psql is not MSSQL nor is it Oraclel.
>You are better off using mongodb and other nosql options
Only if you don't care about your data.
You are not Google, don't pretend to have the scaling problems they do. psql is fine for everything you will ever do.

errr... no they do not. Tech companies like instagram (doesn't use postgres anymore, switched to mysql) and reddt, do not use postgres as a sql database. They use it as a nosql database eg reddts "one big table". They essentially built nosql databases out of sql databases because that is what was available and what they knew at the time.

>psql is fine for everything you will ever do.
but sqlite is even better (the point of this thread) as it is simpler, faster, and as I am discovering, has much nicer nodejs drivers than postgres.

anyone who uses the words toy or power when pertaining to anything programming is automatically a retard

>faster
Absolutely not.
>has much nicer nodejs drivers than postgres
That's a node problem.
SQLite is fine for light uses, prototypes and such, but not for production. You will hit the limits really fast for both performance and features.

sqlite is significantly faster and uses significantly fewer resources, excluding in the case of concurrent write performance.

mongodb is like Java of databases, much slower than C but it just werks. So you should use it for everything.

>sqlite is significantly faster
It's not. It falls apart on simple stuff like COUNT(*).
>uses significantly fewer resources
Debatable, less resources sure, but not significantly.
>excluding in the case of concurrent write performance.
And excluding any scaling whatsoever.

I think you are just making shit up unfortunately. Postgres can be slow on count(*) as well stackoverflow.com/questions/16916633/if-postgresql-count-is-always-slow-how-to-paginate-complex-queries

Neither postgres nor sqlite store the length of a table anywhere, so have to figure it out via a full table scan, or sometimes postgres at least can use indexes, but I don't know how well it works.

I am pretty sure sqlite can also use the index for count... either way, I just think you tried to google shit to save face.

>I think you are just making shit up unfortunately
And I think you never used a RDBMS for anything but simple hobby projects.
>postgres at least can use indexes, but I don't know how well it works.
Yeah, I figured as much.

All of your answers are vague one liners, suggesting you don't actually know anything. I just tried a 20,000 row count in sqlite and it worked instantly. You are using words like "hobby", I assume you are the person who said "toy" before, so it seems you are not very experienced in anything. You haven't provided any kind of technical rebuttal or reasoning for anything. I am the only one providing any technical information, because it appears I am the only one who knows anything. You should first learn things before speaking. Neither postgres not sqlite store table length and both can use indexes when they are covering indexes (cover the entire table in relation to the count query).

Would there be a significant difference in latency between cohabited postgres and sqlite?

unlikely.

Here is another cool thing about sqlite: named parameters. For people who don't use ORMs (cool people), it is much nicer to do

select * from users where id = $id

you can't do that in postgres.

How to create a sqlite database on macos:
in terminal:

sqlite3 my.db

how to create a postgres database:

100 step process. go download, blah blah

sqlite.org/lang_altertable.html#making_other_kinds_of_table_schema_changes

What do you say about this mr sqlite shill?

I am so tired of reading hackernews comments about how everyone should use SQLite for their website or whatever.
And then they always compare it to some strawman of Google Spanner, AWS shit, MongoDB.
>DUDE who needs concurrent writes!?
>DUDE who needs a type system
>DUDE I can just like cp the db file to back it up :^))

Attached: _91408619_55df76d5-2245-41c1-8031-07a4da3f313f.jpg (660x574, 30.86K)

thats a trade-off I can handle.

>I am so tired of reading hackernews comments about how everyone should use SQLite for their website or whatever.
there are even more comments about how everyone should use postgres

>DUDE who needs concurrent writes!?
most people don't even know what they need. people just assume not having concurrent writes makes it slow or unusable without really knowing.
>DUDE who needs a type system
not a big deal to me. many large systems are running mongodb.

>DUDE I can just like cp the db file to back it up :^))
there are other ways. litestream and also just automatic backing up every night. everyone thinks they need some google scale always on 99.999999% reliability 100000k writes a second database when 99% of the databases are being used in enterprises for like 5 users at a time.

>20,000 row count
Now that's a relevant benchmark.