# acid ACID is a set of properties--atomicity, consistency, isolation, and durability--that ensure data integrity in database transactions. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## PostgreSQL as a Microservice DevFeed: [PostgreSQL as a Microservice]() Original publisher: [Read original article]() Author: Dimitri Fontaine PostgreSQL Major Contributor; Author Published: 2021-06-08T11:40:00Z Content type: opinion Language: en Sources: [Dimitri Fontaine]() Topics: [PostgreSQL](), [Concurrency](), [Microservice](), [Architecture & Design](), [acid](), [rdbms]() Tags: [acid](), [architecture](), [concurrency](), [microservices](), [postgresql](), [rdbms]() ### AI overview The article examines PostgreSQL as a potential microservice and argues that its distinctive value is not merely storage. It emphasizes PostgreSQL's role in managing concurrent access to data while providing guarantees such as ACID properties, schemas, and constraints. ### Source excerpt The MACI French podcast honoured me with an invitation to a guest appearance on their weekly schedule. As you can imagine, we talked about many things related to PostgreSQL... and also reacted to some newsworthy articles carefully curated by the MACI team. One of the topics we discussed in the podcast started with looking at PostgreSQL through the angle of it being one of the microservices that your application would be composed of. ## PostgreSQL Concurrency: Isolation and Locking DevFeed: [PostgreSQL Concurrency: Isolation and Locking]() Original publisher: [Read original article]() Author: Dimitri Fontaine PostgreSQL Major Contributor; Author Published: 2018-07-03T11:30:13Z Content type: tutorial Language: en Sources: [Dimitri Fontaine]() Topics: [PostgreSQL](), [Concurrency](), [consistency](), [Transactions](), [acid]() Tags: [acid](), [concurrency](), [consistency](), [locking](), [pg-dump](), [postgresql](), [transactions]() ### AI overview This primer explains PostgreSQL isolation and locking as mechanisms for handling concurrent access while maintaining consistency. It discusses ACID-compliant transactions, isolation levels, locking control, and the snapshot behavior used by pg_dump for backups. ### Source excerpt PostgreSQL is a relational database management system. It's even the world's most advanced open source one of them. As such, as its core, Postgres solves concurrent access to a set of data and maintains consistency while allowing concurrent operations. This article is a primer on PostgreSQL Isolation and Locking properties and behaviors. You might be interested into the previous article in the series: PostgreSQL Concurrency: Data Modification Language. ## The Consistency Series DevFeed: [The Consistency Series]() Original publisher: [Read original article]() Author: Nicolas Liochon (noreply@blogger.com) Published: 2015-05-12T15:43:00Z Content type: article Language: en Sources: [Nicolas Liochon]() Topics: [consistency](), [Databases](), [acid](), [Dynamo](), [CAP theorem]() Tags: [acid](), [availability](), [cap-theorem](), [consistency](), [database](), [databases](), [distributed-system](), [durability](), [dynamo](), [latency](), [network](), [partition](), [series]() ### AI overview The article introduces a new series on consistency models, focusing on practical details and their implementations. It distinguishes the topic from a simple strong-versus-eventual consistency trade-off and previews posts about durability, ACID, and the Dynamo model. ### Source excerpt "Those are my consistency models, and if you don't like them... well, I have others." - Groucho Marx, quoted from memory The CAP theorem series is coming to an end. I have a few posts planned, but they will be mainly about wrapping things-up-- I hope these posts will be great, though. Anyway, here starts a new series: the consistency series. This series is about getting into some practical details about the consistency models and their implementations. You think that the trade-off is only or mainly on strong consistency vs. eventual consistency? That everything is said with "W+R" vs. "N"? Then read this series. Settling on the color may not be enough when choosing a car. Posts, in recommended reading order The posts published so far are: Eventual Consistency and Durability: shows the link between durability and consistency, and why traditional databases have the 'D' in ACID. Tells you what 'W=1' implies in the Dynamo model. ## Why the Author Prefers Relational Databases Over Many NoSQL Systems DevFeed: [Why the Author Prefers Relational Databases Over Many NoSQL Systems]() Original publisher: [Read original article]() Author: Map Published: 2011-11-08T20:55:56Z Content type: opinion Language: en Sources: [Craig Kerstiens]() Topics: [NoSQL](), [acid](), [Databases](), [Transactions](), [SQL](), [Replication](), [backups](), [MySQL](), [Redis]() Tags: [acid](), [backups](), [data](), [databases](), [mysql](), [nosql](), [postgres](), [redis](), [relational-databases](), [replication](), [sql](), [transactions]() ### AI overview The article argues that relational databases are preferable as primary data stores when strong data guarantees matter. It highlights ACID properties, SQL as a broadly shared standard, and the portability of SQL-related skills, while acknowledging that some NoSQL systems can offer speed and may suit exceptions such as reporting applications. ### Source excerpt NoSQL has long been a trend that many have talked about. While there's a place for various key-value stores and tools such as memcache and redis, this will address most specifically how NoSQL is attempting to replace a traditional database. I've long been a fan of postgres and in general traditional relational databases. In a broad sense traditional databases offer multiple things. RDMS Data guarantees The current major SQL databases (SQL Server, Postgres, MySQL, Oracle) offer guarantees around your data that doesn't always exist with other systems. At a very high level this means when they say they have the data there's not a chance they'll loose it. When using something as a primary datastore this is always my first requirement. Data is a valuable commodity so keeping it around is obviously important. There are cases where exceptions exist (reporting applications are common here). The specific thing I always look for is that a system upholds the ACID properties. For a quick breakdown of these: A is for atomic. In short it means no transaction can be partially completed, its all or nothing. C is for consistent. This means you go from one consistent state to another. Meaning things like cascades and constraints are upheld and can't be ignored for a period of time. I is for isolation. This means transactions don't get to interfere with each other. D is for durability. This means once the transactions there its not going anywhere. These basic principles make me feel pretty content with my data being safe. This doesn't include things like backups and replication, but rather is a baseline for me feeling safe with a system. Here's a hint, many NoSQL solutions don't enforce these which is where they get speed from Consistent means for accessing data (SQL) Many people complain about SQL and while its not a perfect language it is a common standard for accessing data. There are idioms that exist in Oracle that do not in Postgres and ones that exist in MySQL that do not in SQ