--- title: One Week Out: Doltgres 1.0 Update | daily.dev description: Doltgres 1.0 is launching August 6th, one week away. Over the past three weeks, 50 pull requests and 136 commits from 9 contributors have landed. Key features... canonical: https://daily.dev/posts/one-week-out-doltgres-1-0-update-bm5g269fo twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: One Week Out: Doltgres 1.0 Update | daily.dev og:description: Doltgres 1.0 is launching August 6th, one week away. Over the past three weeks, 50 pull requests and 136 commits from 9 contributors have landed. Key features... og:url: https://daily.dev/posts/one-week-out-doltgres-1-0-update-bm5g269fo og:image: https://api.daily.dev/og/posts/bM5g269fO.png og:image:alt: One Week Out: Doltgres 1.0 Update og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # One Week Out: Doltgres 1.0 Update **[DoltHub Blog](https://daily.dev/sources/dolthub-blog)** · 10 min read · 10 upvotes · 2 comments ## Summary Doltgres 1.0 is launching August 6th, one week away. Over the past three weeks, 50 pull requests and 136 commits from 9 contributors have landed. Key features now complete include: remotes support (push/pull between Doltgres databases including PostgreSQL-specific entities like sequences and custom types), three replication modes (remote-based, cluster, and PostgreSQL replication) now production-ready, and automatic garbage collection enabled by default. On correctness, Doltgres hit 99% SQL logic test compliance and fixed a notable bind variable type inference bug that could cause silent data corruption with ORMs. Performance has improved past the original 3x Postgres multiplier goal, now targeting 2.6x to match MySQL's relative performance. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What replication options does Doltgres support and which one should I use? Doltgres supports three replication protocols: remote-based replication, cluster replication, and PostgreSQL replication. Remote-based replication is recommended as the simplest default for most use cases. Cluster replication is recommended for high-availability setups since it provides a hot standby ready to become primary on failover. PostgreSQL replication is used when replicating from an existing PostgreSQL server into a Doltgres replica. As of the run-up to Doltgres 1.0, all three are considered production-ready. _Comparing replication strategies for a database migration is easier with technical breakdowns like this on daily.dev._ ### How does automatic garbage collection work in Dolt and Doltgres? Automatic garbage collection runs opportunistically in the background rather than on a fixed schedule, triggering once the data store exceeds an internal size threshold of about 128MB of reclaimable garbage. It removes old, unreferenced row versions left behind by deletes and updates so the data directory shrinks back down automatically, eliminating the need for manually running dolt_gc() or scheduling a cron job. It has been enabled by default in Dolt for roughly a year and is now landing in Doltgres ahead of its 1.0 release. _Track how database internals like garbage collection evolve by following backend engineering updates on daily.dev._ ### What caused Doltgres to write wrong data into a column when using parameterized queries? A bug in Doltgres's bind variable type inference caused it to discard client-provided type information for every parameter in a query whenever even one parameter was left unspecified, then re-infer all of them from scratch. If the re-inferred type didn't match what the client actually sent, Doltgres could misread how many bytes to consume off the wire, leading to incorrect data being written. The fix, in PR #2975, scopes inference to only the parameters that actually need it and makes wire-reading errors fail loudly instead of silently. _Debugging subtle data-correctness bugs gets easier when you follow real-world postmortems like this on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@trevorsuna** · 2 upvotes > The bind-variable fix may be as important as the headline features. Silent ORM corruption is the kind of edge case that makes teams hesitate on a new database; pairing 99% logic-test compliance with production-ready replication makes the 1.0 milestone feel much more credible. **@jenueldev** · 1 upvotes > The remote-based replication flow is elegant, but making a replica check and pull from the remote before every read turns freshness into a latency and availability dependency on that intermediary. For production users, metrics around pull lag, remote failures, and read behavior during an outage would be as important as the happy-path setup—especially because the three replication modes have different recovery semantics. ## Similar posts on daily.dev - [Doltgres 1.0 Coming August 6th](https://daily.dev/posts/doltgres-1-0-coming-august-6th-wyku1t2ei) · DoltHub Blog · 43 upvotes · 4 comments - [Doltgres 1.0](https://daily.dev/posts/doltgres-1-0-dnjnqean4) · DoltHub Blog · 13 upvotes · 2 comments - [Doltgres Reaches 99% Compliance on SQL Logic Tests](https://daily.dev/posts/doltgres-reaches-99-compliance-on-sql-logic-tests-hhnymgooh) · DoltHub Blog · 0 upvotes · 0 comments - [Version Controlled SQL Database Dolt Releases 2.0 with Automatic Storage Cleanup and Compression](https://daily.dev/posts/version-controlled-sql-database-dolt-releases-2-0-with-automatic-storage-cleanup-and-compression-wfaha9aol) · InfoQ · 1 upvotes · 0 comments --- Tags: [#postgresql](https://daily.dev/tags/postgresql), [#version-control](https://daily.dev/tags/version-control) [View this post on daily.dev](https://daily.dev/posts/one-week-out-doltgres-1-0-update-bm5g269fo) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"One Week Out: Doltgres 1.0 Update","url":"https://daily.dev/posts/one-week-out-doltgres-1-0-update-bm5g269fo","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/one-week-out-doltgres-1-0-update-bm5g269fo"},"datePublished":"2026-07-30T23:21:12.522Z","dateModified":"2026-09-14T08:18:38.236Z","description":"Doltgres 1.0 is launching August 6th, one week away. Over the past three weeks, 50 pull requests and 136 commits from 9 contributors have landed. Key features...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/4c88e0a20d29e9290e7487e2f160b1bf?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/4c88e0a20d29e9290e7487e2f160b1bf?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"DoltHub Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"DoltHub Blog","logo":"https://media.daily.dev/image/upload/s--LXDlvjS4--/f_auto,q_auto/v1780213587/logos/dolthub-blog?_a=BAMAMiWQ0","url":"https://daily.dev/sources/dolthub-blog"},"commentCount":2,"discussionUrl":"https://daily.dev/posts/one-week-out-doltgres-1-0-update-bm5g269fo","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":10},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":2}],"keywords":"postgresql,version-control","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"DoltHub Blog","item":"https://daily.dev/sources/dolthub-blog"},{"@type":"ListItem","position":3,"name":"One Week Out: Doltgres 1.0 Update"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/one-week-out-doltgres-1-0-update-bm5g269fo","comment":[{"@type":"Comment","text":"The bind-variable fix may be as important as the headline features. Silent ORM corruption is the kind of edge case that makes teams hesitate on a new database; pairing 99% logic-test compliance with production-ready replication makes the 1.0 milestone feel much more credible.","datePublished":"2026-07-31T02:34:41.881Z","url":"https://daily.dev/posts/bM5g269fO#c-Xg4oI5kE0","author":{"@type":"Person","name":"Trevor Suna","url":"https://daily.dev/trevorsuna","image":"https://media.daily.dev/image/upload/s--dZ7gXxpp--/f_auto/v1784081551/avatars/avatar_EMoP47rpuw8DNjhp6R1b6?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"The remote-based replication flow is elegant, but making a replica check and pull from the remote before every read turns freshness into a latency and availability dependency on that intermediary. For production users, metrics around pull lag, remote failures, and read behavior during an outage would be as important as the happy-path setup—especially because the three replication modes have different recovery semantics.","datePublished":"2026-08-05T04:35:11.590Z","url":"https://daily.dev/posts/bM5g269fO#c-4Gj4ZSyTD","author":{"@type":"Person","name":"Jenuel Oras Ganawed","url":"https://daily.dev/jenueldev","image":"https://media.daily.dev/image/upload/s--BadmiNyj--/f_auto/v1787625077/avatars/avatar_JJtZr4Sjm?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/one-week-out-doltgres-1-0-update-bm5g269fo#faq","mainEntity":[{"@type":"Question","name":"What replication options does Doltgres support and which one should I use?","acceptedAnswer":{"@type":"Answer","text":"Doltgres supports three replication protocols: remote-based replication, cluster replication, and PostgreSQL replication. Remote-based replication is recommended as the simplest default for most use cases. Cluster replication is recommended for high-availability setups since it provides a hot standby ready to become primary on failover. PostgreSQL replication is used when replicating from an existing PostgreSQL server into a Doltgres replica. As of the run-up to Doltgres 1.0, all three are considered production-ready. Comparing replication strategies for a database migration is easier with technical breakdowns like this on daily.dev."}},{"@type":"Question","name":"How does automatic garbage collection work in Dolt and Doltgres?","acceptedAnswer":{"@type":"Answer","text":"Automatic garbage collection runs opportunistically in the background rather than on a fixed schedule, triggering once the data store exceeds an internal size threshold of about 128MB of reclaimable garbage. It removes old, unreferenced row versions left behind by deletes and updates so the data directory shrinks back down automatically, eliminating the need for manually running dolt_gc() or scheduling a cron job. It has been enabled by default in Dolt for roughly a year and is now landing in Doltgres ahead of its 1.0 release. Track how database internals like garbage collection evolve by following backend engineering updates on daily.dev."}},{"@type":"Question","name":"What caused Doltgres to write wrong data into a column when using parameterized queries?","acceptedAnswer":{"@type":"Answer","text":"A bug in Doltgres's bind variable type inference caused it to discard client-provided type information for every parameter in a query whenever even one parameter was left unspecified, then re-infer all of them from scratch. If the re-inferred type didn't match what the client actually sent, Doltgres could misread how many bytes to consume off the wire, leading to incorrect data being written. The fix, in PR #2975, scopes inference to only the parameters that actually need it and makes wire-reading errors fail loudly instead of silently. Debugging subtle data-correctness bugs gets easier when you follow real-world postmortems like this on daily.dev."}}]} ```