Hacker News Reader

Comment by unono | Hacker News Reader

Is there something about sqlite that postgres can't come in to replace it completely (a kind of dynamic postgres that starts up and shuts down like sqlite). With mysql,postgres,and sqlite, the open source db industry gets diluted. Some kind of merger would be great.

edit: to below posters, I'm fully aware sqlite is embedded, i use it everyday for android. I'm just asking if there's actually a technical reason why sqlite and postgres (and mysql) couldn't be merged. A db that can be both embedded or run as server. This would reduce the duplication of effort in open source db community.

View on HN

SQLite isn't a replacement for postgresql (or vice versa). SQLite is a replacement for fopen.

Among its many advantages in that situation: a database is contained in a single file with minimal overhead, the source is shipped as one .c file and encouraged to be statically linked, and the code size is relatively small (compared to something like postgresql).

I hope sqlite someday add functions and/or store procedures. Plus better error messages (like when a foreign key is violated)

Why exactly do you need stored procedures in sqlite? You can just write code. Are you using it in a scenario where you can't write code to interact with sqlite?

For the same reason are used in others DBs.

Some things are better expressed in the DB native language. Help to abstract and share implementation of DBs that are used by different languages.

Why would you want to use PostgreSQL in the contexts that SQLite is used?

SQLite is fantastic when you need a data store for mobile or embedded use, you'd like ad-hoc queries over your data with the option of adding indexes to speed up frequently used ones, you want transactional update to the data, and multi-user access is not a problem.

It's basically a much better replacement for the hash table on a disk approach of DBM libraries.

PostgreSQL would just be total overkill for this kind of scenario.

I just would like the simplicity of use of sqlite on my server. No socket, no connection, no driver that has to match the server, no config file in /etc, no user in /etc/passwd, no cruft.

The separation between the client and server that brings all the 'cruft' makes it a lot simpler to have high performance concurrent operations, a major advantage of a full DBMS over SQLite

> I just would like the simplicity of use of sqlite on my server.

The simplicity comes from largely from not supporting multiple user accounts (authn/authz are left to the owning application), and secondarily (I think) from not being designed to support large numbers of connected processes. If your server need fits that profile, then you can use SQLite and benefit from its simplicity. But if -- as is often the case -- it doesn't, you can't, and its not because no one has merged SQLite with PostgreSQL, its because there is inherent complexity that comes with serving certain use cases.

This is a brilliant idea.

If postgresql could have a single file, embedded mode, then it could replace sqlite.

The advantages of such a design would be: 1. All the optimisations and transaction guarantees of a full-featured DB 2. All the conveniences of a single file DB 3. Better utilisation of open-source resources as the OP points out.

On the other hand, the postgresql system might be bigger (in terms of code size and heap usage) than sqlite. So it may not be feasible to use in all embedded applications.

I think embeddable mode is more realistic than single file since the single user mode used by for example pg_upgrade is quite close to that. Some features are missing though for wide use.

SQLite is database for clients and relatively small application specific databases. Postgres is database for servers.

Your Firefox browser and Skype client come with SQLite.

Reply on news.ycombinator.com