PostgreSQL (alternately Postgres) is a free and open source object-relational database system boasting over 30 years of active development, reliability, feature robustness, and performance. It supports SQL and is designed to support various workloads flexibly.
N/A
SQLite
Score 9.0 out of 10
N/A
SQLite is an in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. The code for SQLite is in the public domain and is thus free for use for any purpose, commercial or private. SQLite is one of the most widely deployed databases in the world.
A free corporate professional product. Who does not want to have such a thing, we hesitated because we did not know the product before and frankly we did not want it at first. But when we give it a chance, it has been running smoothly for years.
PostgreSQL outperforms every other option. It is faster, more flexible, more reliable, easier to maintain, and more consistent in behaviour than any of the other offerings.
The features between these database are quite comparable - except for possibly MongoDB. MongoDB being a different type of database and geared towards big data - I don't compare it to PostgreSQL. The other two I have used and would say PostgreSQL does fairly well when compared …
We looked at other traditional RDBMS products, but found them to be cumbersome to deploy. They take up more space, and consume more computing resources than SQLite does. While the performance or direct integration to our primary applications may have been better or easier if we …
SQLite is considered better against these two depending on the needs and phase of the project. If we require a lightweight yet reliable database which should also be portable across different platforms and speed is the most important part of the query and data security is not …
I think there is no real competition between them. In "SQLite" you can hear "light" when you don't need to store a big amount of data and when you need something easy to deploy, SQLite is a good choice, I didn't find those qualities in other database systems I knew.
PostgreSQL, unlike other databases, is user-friendly and uses an open-source database. Ideal for relational databases, they can be accessed when speed and efficiency are required. It enables high-availability and disaster recovery replication from instance to instance. PostgreSQL can store data in a JSON format, including hashes, keys, and values. Multi-platform compatibility is also a big selling point. We could, however, use all the DBMS’s cores. While it works well in fast environments, it can be problematic in slower ones or cause multiple master replication.
SQLite is a lightweight and efficient database management system. With SQLite, performance increases as memory are added. It's reliable and well-tested before release. SQLite handles memory allocation and I/O errors gracefully. SQLite provides bug lists and code-change chronologies. All bugs are disclosed, and it's compatible with iOS, Android, MAC, and Windows. SQLite is open-source, allowing developers to tailor it to their specific needs.
The stability it offers, its speed of response and its resource management is excellent even in complex database environments and with low-resource machines.
The large amount of resources it has in addition to the many own and third-party tools that are compatible that make productivity greatly increase.
The adaptability in various environments, whether distributed or not, [is a] complete set of configuration options which allows to greatly customize the work configuration according to the needs that are required.
The excellent handling of referential and transactional integrity, its internal security scheme, the ease with which we can create backups are some of the strengths that can be mentioned.
The query syntax for JSON fields is unwieldy when you start getting into complex queries with many joins.
I wish there was a distinction (a flag) you could set for automated scripts vs working in the psql CLI, which would provide an 'Are you sure you want to do X?' type prompt if your query is likely to affect more than a certain number of rows. Especially on updates/deletes. Setting the flag in the headless(scripted) flow would disable the prompt.
Better documentation around JSON and Array aggregation, with more examples of how the data is transformed.
Although it is excellent at what it does, you should be really careful and plan accordingly if you know that your database is going to scale at a huge level because it is not suitable of databases which are of Enterprise level and demands top-notch security and protection.
If your project involves multiple people working on the same database simultaneously, then that becomes a big problem, because it only allows single write at one time. You really need to be forward thinking in a manner to predict if this database will cater to all the needs of your project.
The most common difficulty with this is the lack of some of the basic functionality which is present in the other premier databases like Joints, Stored Procedure calls, Security and permission grants. If you do require all those things then you are better off not using this software.
Lastly, if you are using this in an Andriod App development cycle then also your options are limited because it does not integrate with PostgreSQL and MYSQL.
Postgresql is the best tool out there for relational data so I have to give it a high rating when it comes to analytics, data availability and consistency, so on and so forth. SQL is also a relatively consistent language so when it comes to building new tables and loading data in from the OLTP database, there are enough tools where we can perform ETL on a scalable basis.
I have had a wonderful experience with SQLite because in my every project I use SQLite in the development phase because it's really fast, doesn't crash and very easy to maintain as well. It saves a lot on physical memory and dedicated server usage. It has all the basic functionality you would need to get the job done and that too at no cost at all. What more could you ask for !!!
The data queries are relatively quick for a small to medium sized table. With complex joins, and a wide and deep table however, the performance of the query has room for improvement.
There are several companies that you can contract for technical support, like EnterpriseDB or Percona, both first level in expertise and commitment to the software.
But we do not have contracts with them, we have done all the way from googling to forums, and never have a problem that we cannot resolve or pass around. And for dozens of projects and more than 15 years now.
The online training is request based. Had there been recorded videos available online for potential users to benefit from, I could have rated it higher. The online documentation however is very helpful. The online documentation PDF is downloadable and allows users to pace their own learning. With examples and code snippets, the documentation is great starting point.
Postgres stacks up just [fine] along the other big players in the RDBMS world. It's very popular for a reason. It's very close to MySQL in terms of cost and features - I'd pick either solution and be just as happy. Compared to Oracle it is a MUCH cheaper solution that is just as usable.
We looked at other traditional RDBMS products, but found them to be cumbersome to deploy. They take up more space, and consume more computing resources than SQLite does. While the performance or direct integration to our primary applications may have been better or easier if we had gone with a traditional RDBMS, the performance of SQLite has been more than acceptable. The performance and speed to deploy made SQLite a much more attractive option for us than a traditional RDBMS.
The user-role system has saved us tons of time and thus money. As I mentioned in the "Use Case" section, Postgres is not only used by engineering but also finance to measure how much to charge customers and customer support to debug customer issues. Sure, it's not easy for non-technical employees to psql in and view raw tables, but it has saved engineering hundreds of man-hours that would have had to be spent on building equivalent tools to serve finance or customer support.
It provides incredibly trustworthy storage for wherever customer data dumped in. In our 6 years of Postgres existence, we have not lost a byte of customer data due to Postgres messing up a transaction or during the multiple times the hard-drives failed (thanks to ACID compliance!).
This is less significant, but Postgres is also quite easy to manage (unless you are going above and beyond to squeeze out every last bit of performance). There's not much to configure, and the out of the box settings are quite sane. That has saved us engineers lots of time that would have gone into Postgres administration.
The active community has kept support costs low, further increasing ROI
The wide range of supported platforms and high level of compatibility has increased ROI by reducing time spent porting the database model to any platform specific solutions.
