# Relational Databases Published articles for Relational Databases. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Article: Implementing Durable Workflows on Postgres Without an External Orchestrator DevFeed: [Article: Implementing Durable Workflows on Postgres Without an External Orchestrator]() Original publisher: [Read original article]() Author: Raman Varma Published: 2026-09-14T11:00:00Z Content type: article Language: en Sources: [InfoQ]() Topics: [Databases](), [SQL](), [Provisioning](), [incident](), [CI/CD](), [Kubernetes](), [AWS Step Functions](), [Artificial Intelligence]() Tags: [ai](), [ai-ml-data-engineering](), [architecture-design](), [article](), [automation](), [aws-step-functions](), [database](), [durable-workflows-postgres](), [incident-response](), [infrastructure](), [kubernetes](), [ml-data-engineering](), [orchestration](), [postgres](), [queue](), [relational-databases](), [sql](), [workflows]() ### AI overview This article explains how to implement durable workflows on Postgres without an external orchestrator. It describes using row-level locking as a concurrent work queue, primary-key checkpoints for idempotency, and leases with a sweeper for crash recovery. Workflow state, sleeps, and human approvals can persist in the database and survive process restarts. ### Source excerpt Postgres can serve as the durable state store and coordination layer for workflows, eliminating the need for an external orchestrator. SKIP LOCKED enables concurrent work processing, primary-key checkpoints enforce idempotency, and leases support crash recovery. Workflow sleeps and human approvals can also be persisted as database state and survive restarts. By Raman Varma ## Different Types of Database Management Systems DevFeed: [Different Types of Database Management Systems]() Original publisher: [Read original article]() Author: Sumit Malviya Published: 2026-03-20T10:30:23Z Content type: article Language: en Sources: [Backend Archives | Talent500 blog]() Topics: [Databases](), [Database](), [data](), [Software](), [Scalability](), [NoSQL](), [MongoDB](), [MySQL](), [Oracle Database](), [sql-server]() Tags: [applications](), [backend](), [backup](), [big-data-and-dbms](), [choosing-the-right-dbms-for-your-needs](), [cloud-based-dbms](), [cloud-native](), [comparison-of-dbms-types](), [conclusion](), [consistency](), [data](), [database](), [definition-and-importance-of-dbms](), [different-types-of-database-management-systems](), [emerging-types-in-database-management-systems](), [evolution](), [evolution-of-database-management-systems](), [examples](), [hierarchical-database-management-systems](), [industries](), [integrity](), [management](), [mysql](), [network-database-management-systems](), [nosql](), [nosql-databases](), [object-oriented-database-management-systems-oodbms](), [recovery](), [relational-database-management-systems-rdbms](), [relational-databases](), [scalability](), [systems](), [types](), [types-of-database-management-systems]() ### AI overview This article explains what database management systems are, why they matter, how they support storage, queries, security, integrity, backup, and recovery, and how major DBMS categories have evolved. It also introduces examples including MySQL, Oracle Database, Microsoft SQL Server, and MongoDB. ### Source excerpt Data is one of the most valuable assets for organizations in this AI-powered digital era. From banking systems and e-commerce [...] The post Different Types of Database Management Systems appeared first on Talent500 blog. ## Breaking the Loop: How we migrated our backup catalog for 250+ MySQL clusters to AWS DevFeed: [Breaking the Loop: How we migrated our backup catalog for 250+ MySQL clusters to AWS]() Original publisher: [Read original article]() Author: Ioannis Androulidakis Published: 2026-02-19T14:19:52Z Content type: article Language: en Sources: [Booking.com Development - Medium]() Topics: [migration](), [Amazon RDS](), [MySQL](), [Amazon Web Services](), [backups](), [Cloud](), [on-prem]() Tags: [amazon-rds](), [aws](), [backup](), [cloud](), [cloud-migration](), [data-backup](), [database](), [databases](), [migration](), [mysql](), [on-prem](), [relational-databases](), [reliability-engineering]() ### AI overview Booking.com's Database Engineering team describes migrating the backup catalog orchestrator's backend for more than 250 production MySQL clusters from a self-managed on-premises MySQL database to managed Amazon RDS for MySQL in AWS. The article discusses the migration's challenges, implemented solutions, and lessons learned. ### Source excerpt This post was originally published internally on May 9, 2025 and has been reworked for a public audience. Authors: Ioannis Androulidakis, Mohammed Gaafar Intro The Database Engineering team at Booking.com is constantly looking for ways to improve database reliability and support scaling our business. In 2025 we completed a major milestone in our effort to modernize our infrastructure: we seamlessly migrated the backend of the orchestrator that schedules and manages the daily backups of 250+ production MySQL clusters. More specifically, we moved from a self-managed MySQL database running on premises to a managed Amazon RDS MySQL database running in the cloud. This blog post delves into the challenges we faced, the solutions we implemented, and some key lessons we learned along the way. We are moving to the cloud (gradually) Cloud adoption is a journey, not a switch. Over the past few years the adoption of AWS solutions at Booking.com has been growing rapidly across different business units, allowing teams to be more autonomous, run their databases in the cloud and solve known issues with their old on-premise setup. Like customer teams, we are running our own databases to power the core services that we offer and manage databases efficiently at scale. To name a few: automatic failover of writable primaries, auto-scaling of read-only replicas, service discovery, capacity planning, online schema changes, user access management, volume backups, etc. Traditionally, the Database Engineering team has been running databases on-premises. In the emerging era of cloud databases, we wanted to compare our in-house offerings with existing cloud databases and bridge the gap between the two. Knowing that we lacked deep, hands-on experience with the operational realities of running critical infrastructure on AWS, we saw this as a unique opportunity to learn more about cloud databases while also improving the reliability of our systems. Long story short, we decided to prioritize the m ## Branching as the New Standard for Relational Databases DevFeed: [Branching as the New Standard for Relational Databases]() Original publisher: [Read original article]() Author: Carlota Soto Published: 2025-07-10T16:51:48Z Content type: opinion Language: en Sources: [Blog -- Neon Docs]() Topics: [Databases](), [Development](), [AI Development](), [cloud-infrastructure]() Tags: [agent](), [ai](), [databases](), [development](), [infra](), [migrations](), [product](), [relational-databases](), [software-development](), [workflows]() ### AI overview The article argues that relational databases have lagged behind the software stack in iteration speed, automation, and developer experience. It presents database branching as a new standard for development workflows, especially because AI agents need databases that are fast to provision, scalable, integrated, cost-efficient, and easy to discard. ### Source excerpt Over the last decade, nearly every part of the software development stack has evolved to support faster iteration, better automation, and less oversight. But one layer has stubbornly resisted this evolution - the relational database. The stack evolved, the database stayed behind... ## Migrating From PostgreSQL to MongoDB in a .NET EF Core Application DevFeed: [Migrating From PostgreSQL to MongoDB in a .NET EF Core Application]() Original publisher: [Read original article]() Author: Luce Carter Published: 2025-05-01T12:00:00Z Content type: tutorial Language: en Sources: [Nic Raboy]() Topics: [MongoDB](), [PostgreSQL](), [.NET](), [Object-relational mapping](), [migration](), [Databases](), [Development]() Tags: [algorithms](), [azure](), [dotnet](), [efcore](), [genai](), [migration](), [mongodb](), [net](), [orm](), [postgres](), [postgresql](), [relational-databases]() ### AI overview This tutorial explains how to migrate a .NET application using PostgreSQL and Entity Framework Core to MongoDB with the MongoDB EF Core Provider. It also describes using Relational Migrator to transform relational data and model it for MongoDB collections. ### Source excerpt For many reasons--including scalability, flexibility, and modernization--more and more development teams are looking to migrate away from PostgreSQL to MongoDB. In the past, these teams might have been ... The post Migrating From PostgreSQL to MongoDB in a .NET EF Core Application appeared first on DEV. ## Is your AWS RDS bill bloated? DevFeed: [Is your AWS RDS bill bloated?]() Original publisher: [Read original article]() Author: Carlota Soto Published: 2024-09-25T19:46:25Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [Amazon Web Services](), [Databases](), [Database](), [cloud-infrastructure]() Tags: [aws](), [capacity](), [company](), [compute](), [database](), [databases](), [devops](), [relational-databases]() ### AI overview The article examines why AWS RDS database bills become unnecessarily high. It attributes the cost primarily to overprovisioned production databases and development or test environments that remain provisioned continuously despite limited usage. Survey results indicate that many teams use allocated compute capacity for only part of the day while maintaining multiple, relatively large non-production databases. ### Source excerpt "We definitely were wasting money in unused compute. We could have used burstable instances, we could have shut down servers at night--but the pressures of the daily tasks never gave us the time to get to it" (Director of Sofware Engineering) We see this all the time: companies us... ## The crushing success of relational databases DevFeed: [The crushing success of relational databases]() Original publisher: [Read original article]() Author: Andy Hattemer Published: 2024-08-13T20:27:05Z Content type: opinion Language: en Sources: [Blog -- Neon Docs]() Topics: [Databases](), [SQL](), [Hadoop](), [Graphs]() Tags: [databases](), [graphs](), [hadoop](), [postgres](), [relational-databases](), [sql]() ### AI overview The article argues that relational databases remain dominant because they repeatedly absorb capabilities associated with competing data models and query systems. It presents document, vector, and graph functionality as features that can coexist within a relational database, and revisits arguments that the relational model will continue to outlast attempted replacements. ### Source excerpt Every once in a while, a revolutionary product comes along and changes everything. And today, we're talking about three of these phenomenal products. The first one is a document store. The second is a vector database. And the third is a graph database. So, three things: document... ## SQL vs NoSQL Explained DevFeed: [SQL vs NoSQL Explained]() Original publisher: [Read original article]() Author: Nelson Djalo Published: 2024-07-02T16:00:57Z Content type: comparison Language: en Sources: [Amigoscode Newsletter]() Topics: [NoSQL](), [SQL](), [Databases](), [clickhouse]() Tags: [acid](), [business-intelligence](), [consistency](), [data-analysis](), [database](), [database-scalability](), [durability](), [microsoft](), [mysql](), [nosql](), [olap](), [oracle](), [postgresql](), [rdbms](), [relational-database-management-systems-rdbms](), [relational-databases](), [schema](), [sql]() ### AI overview This comparison explains the differences between SQL and NoSQL databases, including their characteristics, scalability models, and common use cases. It covers SQL database features such as structured schemas and ACID compliance, along with relational and OLAP database categories. ### Source excerpt Choosing the Right Database for Your Needs ## Relational Databases on AWS: Comparing RDS and Aurora DevFeed: [Relational Databases on AWS: Comparing RDS and Aurora]() Original publisher: [Read original article]() Author: Guillermo Ojeda Published: 2024-04-23T23:40:12Z Content type: comparison Language: en Sources: [Guille Ojeda]() Topics: [Amazon Web Services](), [Amazon Aurora](), [Amazon RDS](), [Databases](), [Architecture & Design](), [Scalability]() Tags: [amazon-aurora](), [amazon-rds](), [architecture](), [aws](), [backup](), [compare](), [databases](), [high-availability](), [performance](), [pricing](), [recovery](), [relational-databases](), [scalability]() ### AI overview This comparison examines Amazon RDS and Amazon Aurora, two managed relational database services in AWS. It describes RDS features including supported database engines, scaling options, storage choices, pricing factors, and automated backup and restore capabilities. ### Source excerpt There are two managed relational database services in AWS: Amazon Relational Database Service (RDS) and Amazon Aurora. Both provide the benefits of a fully managed database solution, but they have distinct features and use cases. In this article, we'... ## Scaling Challenge Leaderboards for Millions of Athletes DevFeed: [Scaling Challenge Leaderboards for Millions of Athletes]() Original publisher: [Read original article]() Author: Mike Kasberg Published: 2024-01-18T17:01:41Z Content type: article Language: en Sources: [Strava Engineering]() Topics: [Scalability](), [systems](), [Redis](), [legacy]() Tags: [implementation](), [legacy](), [programming](), [redis](), [relational-databases](), [scalability](), [sql](), [system-design-concepts](), [systems]() ### AI overview A Strava Engineering blog post describes replacing a legacy challenge leaderboard system after rapid growth in monthly challenge participation caused recurring bottlenecks and scalability problems. The article introduces the scaling challenges of the old system, which was implemented primarily using Redis. ### Source excerpt Strava challenges offer a fun way for athletes to compete against themselves and others! Back in 2020, our legacy challenge leaderboard system was running into bottlenecks and scalability problems on a regular basis, and we often found ourselves putting out fires to keep the system stable. In late 2020 and early 2021, I worked on a project to replace the old leaderboard system with a new one that could handle a much larger number of athletes competing in challenges. This blog post is about that project. I drafted most of this post when the project wrapped up in 2021, but didn't get it published before I went on paternity leave -- and then I forgot about it. I think the project was interesting and worth sharing, so I'm glad I finally remembered my draft (three years later 🫣) and found some time to put in the finishing touches and get it published! Enjoy! In January 2020, Strava's monthly 5K running challenge attracted more than half a million participants for the first time. This was a big milestone, doubling the participation from just a year earlier when we had only a little more than 250,000 participants in the January 2019 5K challenge. But we weren't done growing! Just 5 months later, our challenge participants doubled again and we broke 1 million participants in a monthly challenge for the first time with the May 2020 5K, where 1.2 million Strava athletes participated! In less than a year and a half, the number of athletes participating in Strava's monthly challenges had quadrupled. As you can imagine, the increase in challenge participation came with a significant increase in load on our systems. In particular, we were beginning to approach the limits of what our existing challenge leaderboard system could handle. If the number of challenge athletes participating in our monthly challenges were to double again, our challenge leaderboard system wouldn't handle it well. We needed to do something to improve the way our leaderboard system scaled with more challenge ## What is a distributed database and how do they work? DevFeed: [What is a distributed database and how do they work?]() Original publisher: [Read original article]() Author: Charlie Custer Published: 2023-10-09T00:00:00Z Content type: tutorial Language: en Sources: [Cockroach Labs]() Topics: [Databases](), [Architecture & Design](), [Resilience](), [Cloud](), [Microservice]() Tags: [architecture](), [cloud](), [database](), [distributed](), [microservices](), [relational-databases](), [resilience](), [scale]() ### AI overview This article explains what distributed databases are, how they run data across multiple interconnected computers or nodes, and why they are used. It describes their resilience during instance outages and their suitability for scaling cloud applications and mission-critical workloads. ### Source excerpt The cloud is, by definition, a distributed system. Distributed application architecture is mainstream in the world of software -- you wouldn't build any other way. For more than a decade, though, the database has lagged behind. The architecture of traditional relational databases frequently conflicts with the architectural needs of modern cloud applications: horizontal scale, elasticity, and microservices. ## Upsert in SQL: What is an upsert, and when should you use one? DevFeed: [Upsert in SQL: What is an upsert, and when should you use one?]() Original publisher: [Read original article]() Author: Charlie Custer Published: 2023-05-08T00:00:00Z Content type: tutorial Language: en Sources: [Cockroach Labs]() Topics: [SQL](), [Databases](), [CockroachDB](), [MySQL](), [PostgreSQL]() Tags: [cockroachdb](), [database](), [mysql](), [postgresql](), [rdbms](), [relational-databases](), [sql](), [update]() ### AI overview This tutorial explains SQL upserts, an operation that updates an existing row when a specified value is present and inserts a new row when it is not. It discusses why the term may be absent from database documentation and introduces implementation approaches for CockroachDB, MySQL, and PostgreSQL. ### Source excerpt Upserts are useful for anyone who works with a database to know, but the term "upsert" might not even appear in your DBMS's documentation! So what is an upsert, anyway? And why might it not be mentioned in your docs? ## DevOps at Findmypast: Postgres Database Upgrades DevFeed: [DevOps at Findmypast: Postgres Database Upgrades]() Original publisher: [Read original article]() Author: Robbie Hill Published: 2022-11-17T11:30:00Z Content type: article Language: en Sources: [Findmypast]() Topics: [Databases](), [DevOps](), [upgrade](), [Microservices](), [Kubernetes](), [Puppet](), [Ubuntu]() Tags: [back-end](), [clusters](), [configuration](), [databases](), [deployment](), [devops](), [engineering](), [findmypast](), [kubernetes](), [kubernetes-clusters](), [linux](), [microservices](), [mongodb](), [postgres](), [puppet](), [relational-databases](), [ubuntu](), [updates](), [upgrade](), [upgrades]() ### AI overview Findmypast describes its process for upgrading production and non-production Postgres databases. The article covers the database infrastructure, backup arrangements, Puppet-managed installations, version drift between environments, and the reasons for standardizing on the latest supported Postgres version. ### Source excerpt Introduction Findmypast and its sister site; the British Newspaper Archive (BNA), are served by a web of microservices operating across multiple Kubernetes clusters. A number of our microservices rely upon a back-end database, and although we do operate other database technologies (MSSQL, MongoDB etc.), Postgres is our de-facto standard for relational databases. When the DevOps team first realised the need to upgrade all of the database nodes to the latest Postgres version, we operated a total of twelve production Postgres databases, each running on their own dedicated Ubuntu Linux virtual machine (VM). Running on standalone VMs allows for separation of concerns, and limits the 'blast radius' of issues and failures should they occur. All VMs are managed by our Hyper-V cluster, and backed up regularly by Veeam. In addition to this backup method we operate Barman, which takes a full backup of all production Postgres database hosts nightly, and continuously receives WAL (Write Ahead Log) updates. We operate a a similar number of staging / integration / utility Postgres databases. Unlike the production databases these are (mostly) co-located on a single host, given the reduced storage and performance requirements of these databases. Existing Processes We manage Postgres installations and configuration through Puppet, pinning the installed version of Postgres. After the initial deployment we were not actively upgrading the Postgres version running on the hosts. Upgrades of the production databases were instead only undertaken by the feature teams (those teams that manage our micro-services), or by us when requested by the feature teams. This meant that we had a variety of Postgres databases deployed to production, between versions 9 and 14 (the latest supported version at the time). It also meant that the Production Postgres versions differed from their respective staging / integration database. We knew this situation, as well as the approach to upgrades was bad practice ## pg\_jsonschema: JSON Schema support for Postgres DevFeed: [pg\_jsonschema: JSON Schema support for Postgres]() Original publisher: [Read original article]() Author: Oliver Rice Published: 2022-08-19T07:00:00Z Content type: article Language: en Sources: [Supabase Blog]() Topics: [JSON Schema](), [JSON](), [Supabase](), [SQL](), [Databases](), [MongoDB]() Tags: [blog](), [json](), [json-schema](), [postgres](), [relational-databases](), [sql](), [validation]() ### AI overview Supabase introduces pg_jsonschema, a Postgres extension that adds JSON Schema validation for JSON data. The article explains how validating document-shaped webhook payloads can preserve flexibility while enforcing required structure and constraints. ### Source excerpt Today we're releasing pg_jsonschema, a Postgres extension for JSON validation. ## What is SELECT FOR UPDATE in SQL (with examples)? DevFeed: [What is SELECT FOR UPDATE in SQL (with examples)?]() Original publisher: [Read original article]() Author: Charlie Custer Published: 2022-06-27T00:00:00Z Content type: tutorial Language: en Sources: [Cockroach Labs]() Topics: [SQL](), [Databases](), [Transactions](), [CockroachDB](), [consistency](), [MySQL](), [SQLite](), [Latency]() Tags: [cockroachdb](), [consistency](), [databases](), [latency](), [mysql](), [performance](), [relational-databases](), [sql](), [sqlite](), [transactions]() ### AI overview This tutorial explains SELECT FOR UPDATE in SQL, including how it locks rows during transactions, queues competing transactions, and can reduce retries and tail latency. It compares support and transaction behavior across MySQL, SQLite, and CockroachDB. ### Source excerpt Relational databases are great for transactional workloads. But things can get messy when multiple transactions start trying to access the same data at the same time. Luckily, in many SQL databases there's a solution for that: SELECT FOR UPDATE. ## What is a Graph Database? | Why GraphQL is Not a Graph Database DevFeed: [What is a Graph Database? | Why GraphQL is Not a Graph Database]() Original publisher: [Read original article]() Author: Khalil Stemmler Published: 2021-11-25T21:40:19Z Content type: article Language: en Sources: [Apollo Blog]() Topics: [graph-database](), [GraphQL](), [Databases](), [Database](), [Transactions]() Tags: [database](), [fraud-detection](), [graph](), [graph-database](), [graphql](), [management](), [network](), [relational-databases](), [transactions]() ### AI overview This educational article explains what graph databases are, how they model data with nodes, edges, and properties, when they are useful for relationship analysis, and how they differ from GraphQL and relational databases. ### Source excerpt GraphQL is a query language and a server-side runtime (typically served over HTTP). However, you may have also heard of graph databases. What does GraphQL have to do with graph databases? Not so much. In this post, we'll clear up any confusion you may have about GraphQL and graph databases by learning about what graph databases are, the main ideas behind them, when they're most valuable, and how they differ from GraphQL. What is a graph database? ## Beyond LIMIT, Presto meets OFFSET and TIES DevFeed: [Beyond LIMIT, Presto meets OFFSET and TIES]() Original publisher: [Read original article]() Author: Piotr Findeisen, Starburst Data Published: 2020-02-03T00:00:00Z Content type: article Language: en Sources: [Trino Blog]() Topics: [SQL](), [Databases](), [big-data]() Tags: [big-data](), [relational-databases](), [sql]() ### AI overview The article explains how Presto added ANSI SQL support for limiting query results, including skipping initial rows with OFFSET and retaining all rows tied with the final result using TIES. It contrasts the standard syntax with Presto's existing shorthand and discusses its usefulness for ad-hoc queries over big data sets. ### Source excerpt Presto follows the SQL Standard faithfully. We extend it only when it is well justified, we strive to never break it and we always prefer the standard way of doing things. There was one situation where we stumbled, though. We had a non-standard way of limiting query results with LIMIT n without implementing the standard way of doing that first. We have corrected that, adding ANSI SQL way of limiting query results, discarding initial results and - a hidden gem - retaining initial results in case of ties. ## Amazon RDS Proxy makes it easier to use SQL in Serverless DevFeed: [Amazon RDS Proxy makes it easier to use SQL in Serverless]() Original publisher: [Read original article]() Author: Alex DeBrie Published: 2019-12-03T00:00:00Z Content type: article Language: en Sources: [Serverless Blog]() Topics: [Amazon RDS](), [Serverless](), [SQL](), [Databases]() Tags: [amazon-rds](), [applications](), [aws](), [aws-lambda](), [cloud-computing](), [faas](), [function-as-a-service](), [infrastructure-as-code](), [news](), [post](), [proxy](), [re](), [relational-databases](), [release](), [serverless](), [serverless-architecture](), [serverless-framework](), [sql]() ### AI overview Amazon RDS Proxy is presented as addressing a major objection to using relational databases in serverless applications by making SQL easier to use in serverless environments. ### Source excerpt The release of the Amazon RDS Proxy at re:Invent removes one of the main objections to using relational databases in serverless applications. Read this post to understand why. ## Five Common Data Stores and When to Use Them DevFeed: [Five Common Data Stores and When to Use Them]() Original publisher: [Read original article]() Author: Toria Gibbs Published: 2019-10-15T19:15:00Z Content type: article Language: en Sources: [Shopify Engineering](), [Shopify Engineering - Shopify Engineering]() Topics: [data](), [Databases](), [MySQL](), [SQL](), [Structured-data](), [NoSQL](), [Transactions](), [Scalability](), [systems](), [Shopify]() Tags: [article](), [data](), [database](), [databases](), [mysql](), [queue](), [relational-databases](), [scalability](), [search](), [sql](), [storage](), [technical](), [transactions]() ### AI overview This article introduces five common data stores--relational databases, NoSQL databases, key-value stores, full-text search engines, and message queues--and discusses their attributes and appropriate uses. It explains relational database concepts such as schemas, tables, primary keys, foreign keys, and SQL, and notes that Shopify uses MySQL as its relational database management system. ### Source excerpt An important part of any technical design is choosing where to store your data. This post describes five common data stores and their attributes. ## Modeling Polymorphism in Django DevFeed: [Modeling Polymorphism in Django]() Original publisher: [Read original article]() Author: Haki Benita Published: 2019-01-01T22:00:00Z Content type: tutorial Language: en Sources: [Haki Benita]() Topics: [Polymorphism](), [Django](), [Object-relational mapping](), [Database]() Tags: [article](), [articles](), [django](), [orm](), [polymorphism](), [relational-databases](), [techniques]() ### AI overview The article presents several techniques for modeling polymorphic objects in relational databases using Django's object-relational mapping (ORM). ### Source excerpt Modeling polymorphism in relational databases is a challenging task. In this article, we present several modeling techniques to represent polymorphic objects in a relational database using the Django object-relational mapping (ORM). ## Auto incrementing IDs for MongoDB DevFeed: [Auto incrementing IDs for MongoDB]() Original publisher: [Read original article]() Author: masnun Published: 2018-12-06T17:14:35Z Content type: tutorial Language: en Sources: [Abu Ashraf Masnun]() Topics: [MongoDB](), [pymongo](), [Databases](), [MySQL](), [PostgreSQL]() Tags: [code](), [deprecated](), [general](), [mongodb](), [mysql](), [nosql](), [operator](), [postgresql](), [pymongo](), [python](), [relational-databases]() ### AI overview This tutorial explains how to implement sequential, auto-incrementing IDs in MongoDB using a separate collection that stores the last used numeric ID. It describes atomically incrementing the value before inserting a document and notes that the older find-and-modify approach is deprecated. ### Source excerpt If you're familiar with relational databases like MySQL or PostgreSQL, you're probably also familiar with auto incrementing IDs. You select a primary key for a table and make it auto incrementing. Every row you insert afterwards, each of them gets a new ID, automatically incremented from the last one. We don't have to keep track [...] The post Auto incrementing IDs for MongoDB appeared first on Abu Ashraf Masnun. ## SQL Keys in Depth DevFeed: [SQL Keys in Depth]() Original publisher: [Read original article]() Published: 2018-01-01T00:00:00Z Content type: article Language: en Sources: [Joe Nelson]() Topics: [Databases](), [SQL](), [Structured-data]() Tags: [articles](), [databases](), [relational-databases](), [sql]() ### AI overview An in-depth discussion of keys in relational databases, including the debate over natural and artificial keys, the definition of a key as an irreducibly unique column or column combination, and examples involving card tables and database-enforced constraints. ### Source excerpt 2018-01-01 The internet is full of dogmatic commandments for choosing and using keys in relational databases. At times it verges on a holy war: should you use natural or artificial keys? Auto-incrementing integers, UUIDs? After wading through sixty-four articles, skimming sections in five books, and asking questions on IRC and StackOverflow I think I've put the pieces together and have a recommendation to harmonize the various camps. ## Deferrable SQL Constraints in Depth DevFeed: [Deferrable SQL Constraints in Depth]() Original publisher: [Read original article]() Published: 2017-08-27T00:00:00Z Content type: tutorial Language: en Sources: [Joe Nelson]() Topics: [Databases](), [PostgreSQL](), [SQL](), [Transactions]() Tags: [2017](), [automatic](), [database](), [databases](), [errors](), [postgresql](), [procedural](), [relational-databases](), [sql](), [transactions]() ### AI overview An in-depth explanation of deferrable SQL constraints, focusing on how PostgreSQL lets transactions postpone constraint checks while preserving data correctness. ### Source excerpt 2017-08-27 One strength of relational databases is their constant vigilance over data correctness. The user can declare constraints that their data must obey, and then leave it to the database to enforce the rules. This saves a lot of procedural application code and potential errors. Automatic constraint enforcement is a powerful feature, and should be leveraged whenever possible. However there are times when it is convenient - and even necessary - to temporarily defer enforcement. ## Rethinking the limits on relational databases DevFeed: [Rethinking the limits on relational databases]() Original publisher: [Read original article]() Author: Map Published: 2014-01-24T20:55:56Z Content type: opinion Language: en Sources: [Craig Kerstiens]() Topics: [Databases](), [NoSQL](), [migration](), [MongoDB](), [couchdb](), [Object-relational mapping](), [JSON](), [PostgreSQL](), [Django](), [Rails]() Tags: [couchdb](), [databases](), [django](), [json](), [migration](), [mongodb](), [orm](), [postgres](), [postgresql](), [rails](), [relational-databases]() ### AI overview This opinion argues that useful ideas associated with schema-less databases could be applied to relational databases. It focuses on reducing migration friction through frameworks or ORMs and on supporting document-like JSON storage in relational systems. ### Source excerpt Theres a lot of back and forth on NoSQL databases. The unfortunate part with all the back and forth and unclear definitions of NoSQL is that many of the valuable learnings are lost. This post isn't about the differences in NoSQL definitions, but rather some of the huge benefits that do exist in whats often grouped into the schema-less world that could easily be applied to the relational world. Forget migrations Perhaps the best thing about the idea of a schemaless database is that you can just push code and it works. Almost exactly five years ago Heroku shipped git push heroku master letting you simply push code from git and it just work. CouchDB and MongoDB have done similar for databases... you don't have to run CREATE TABLE or ALTER TABLE migrations before working with your database. There's something wonderful about just building and shipping your application without worrying about migrations. This is often viewed as a limitation of relational databases. Yet it doesn't really have to. You see even in schema-less database the relationships are still there, its just you're managing it at the application level. There's no reason higher level frameworks or ORMs couldn't handle the migration process. As it is today the process of adding a column to a relational database is quite straightforward in a sense where it doesn't introduce downtime and is capable of letting the developer still move quickly its just not automatically baked in. # Assuming a column thats referenced doesn't exist # Automatically execute relevant bits in your ORM # This isn't code meant for you to run ALTER TABLE foo ADD COLUMN bar varchar(255); # This is near instant # Set your default value in your ORM UPDATE TABLE foo SET bar = 'DEFAULT VALUE' WHERE bar IS NULL; ALTER TABLE foo ALTER COLUMN bar NOT NULL; Having Rails/Django/(Framework of your choice) automatically notice the need for a column to exist and make appropriate modifications you could work with it the same way you would managing a doc [Next page]()