# RegattaDB - Full Content Corpus > Complete text of published CMS pages, articles, resources, and press or analyst entries on regatta.dev. Structured summary and link index: https://regatta.dev/llms.txt Site: https://regatta.dev/ Documentation: https://docs.regatta.dev Contact: info@regatta.dev ## Contents - About Us - Connectors - Contact us - RegattaDB Developer License Agreement - Regatta End-User License Agreement - Get Started for [[Free]] - Regatta 2026 Homepage - Press & Analysts - Privacy Policy - Terms of Service - Use Cases - When Rows Outgrow the Page: RegattaDB vs. PostgreSQL TOAST - Imagining OpenAI’s 800-million-users PostgreSQL at scale without replicas or offloading, on RegattaDB - Just added: Watch RegattaDB vs. PostgreSQL: 8.6x Faster Inserts, 25x Faster Scans - Under the Hood of RegattaDB's Vector Index - Databricks LTAP Revisited: The Compute Cost of Bridging Two Engines - Press Release: RegattaDB Launches as the Database Built for AI Agents - Databricks LTAP and the Unfinished Problem of Unified Data - We Rebuilt Our Website, Because We Rethought the Database - The Case for a Single, Distributed Database Under Growing Infrastructure Constraints - What workloads can you converge with RegattaDB? - NVIDIA’s Agentic Era: The Bottleneck Isn't GPUs, It’s Your Database - RegattaDB TPC-C Benchmark: 750,000 TPS - File under “now possible”: A 20B row JOIN and 50,000 UPDATES/second in a single distributed database - The Shift to Agentic AI and a Modern Database - RegattaDB: Concurrency Control - Serializable Isolation Without Locks, Snapshots or Clock Sync - Connect Your Spring Boot Application to RegattaDB - RegattaDB’s Architecture: A Bird’s Eye View - Sharding - some dirty little secrets - RegattaDB: Simple beats complex – more detail - RegattaDB linear scaling & no-compromise ACID in more detail - Private Company Spotlight - Real-Time Stock Trading Analytics Demo with AI Agent - Dirty Secrets of Sharding Whitepaper - Creating a Table and Inserting Data - Creating a Regatta Cluster - CRUD Operations - Linear Scaling Demo - Python Integration with Regatta - Node.js Integration with Regatta - Kafka Integration with Regatta - Build your JavaScript application with Regatta - Demonstration: Regatta Linear Scaling Part II - Demonstration: Regatta Linear Scaling Part I - Demonstration: Integrating Regatta with Streaming/Event Data - RegattaDB: High-Performance Database Built for Agentic AI - Private Company Spotlight - Unifying Data Stacks, Open-Weight Controversies & Google's Anti-Gravity CLI - RegattaDB Arrives: A Unified Engine Built for the Era of Read-Write AI - Regatta Data Launches RegattaDB for AI Agent Workloads - AI Database War Begins: Is RegattaDB the Breakthrough That Could Finally Replace Legacy Data Systems? - Regatta Data launches unified base for AI with RegattaDB - Regatta launches its unified OLTP, OLAP and vector database - RegattaDB Launches as the Database Built for AI Agents - Unifying OLTP, OLAP, and Vectors - Dell PowerFlex/Regatta database combo overcomes trad database limitations - Flash-centric Regatta OLxP database working on faster access for AI agents - Database startup Regatta emerges from stealth mode --- # About Us Source: https://regatta.dev/about-us Updated: 2026-08-04 We are a team of storage, database and distributed systems veterans who've spent careers building infrastructure that powers the world's largest organizations... --- # Connectors Source: https://regatta.dev/connectors Updated: 2026-08-18 RegattaDB integrates with popular programming languages, frameworks, and data platforms, making it easy to connect your applications and workflows. --- # Contact us Source: https://regatta.dev/contact-us Updated: 2026-08-20 Want to see RegattaDB in action, or have a question? Share your details and a Regatta team member will reach out shortly. --- # RegattaDB Developer License Agreement Source: https://regatta.dev/dla Updated: 2026-06-14 IMPORTANT – READ CAREFULLY BEFORE DOWNLOADING, INSTALLING OR USING REGATTADB (THE “SOFTWARE”). NOTE THE TERM “SOFTWARE” AS USED HEREIN SHALL ALSO INCLUDE INTERNET-BASED AND OTHER DATABASE SERVICES PROVIDED BY REGATTA DATA LTD. (“LICENSOR”) THROUGH THE SOFTWARE (THE “SERVICES”), AND ANY PATCHES, UPDATES, MODIFIED VERSIONS, SERVICE PACKS AND UPGRADES WHICH MAY BE PROVIDED BY THE LICENSOR FROM TIME TO TIME (IF ANY). BY USING THE SOFTWARE AND/OR SERVICES, YOU (“YOU” OR ”LICENSEE”) ACKNOWLEDGE THAT THE LICENSEE HAS READ THIS LICENSE AGREEMENT (“AGREEMENT”), THAT LICENSEE UNDERSTANDS IT, AND IS CONSENTING TO BE BOUND BY AND BECOMING A PARTY TO THIS AGREEMENT. IF LICENSEE DOES NOT AGREE TO ALL OF THE TERMS OF THIS AGREEMENT, LICENSEE SHOULD NOT USE THE SOFTWARE AND/OR SERVICES. FURTHERMORE, BY ACCEPTING THE TERMS OF THIS AGREEMENT, LICENSEE HEREBY WAIVES ANY RIGHTS OR REQUIREMENTS UNDER ANY LAWS OR REGULATIONS IN ANY JURISDICTION WHICH REQUIRE AN ORIGINAL (NON-ELECTRONIC) SIGNATURE OR DELIVERY OR RETENTION OF NON-ELECTRONIC RECORDS, TO THE MAXIMUM EXTENT PERMITTED UNDER APPLICABLE LAW. IF YOU ARE NOT THE LICENSEE AND YOU INSTALL THIS SOFTWARE AND/OR USE THE SERVICES ON BEHALF OF THE LICENSEE, YOU WARRANT AND REPRESENT THAT YOU ARE AUTHORIZED TO ACT ON BEHALF OF THE LICENSEE AND TO ACCEPT AND BIND THE LICENSEE TO THE TERMS OF THIS AGREEMENT. 1. Developer License Grant Subject to and conditioned upon Licensee’s compliance with the terms and conditions of this Agreement, Licensor hereby grants to Licensee, and Licensee accepts, a limited, nonexclusive, nontransferable, revocable license to use the Software (in machine-readable, object code form only) and the Services strictly for internal testing and evaluation purposes. Licensee agrees not to assign, sublicense, transfer, pledge, lease, rent, or share Licensee’s rights under this Agreement. Except as specifically authorized under this paragraph, no copies of the Software or any portions thereof may be made by Licensee or any person under Licensee’s authority or control. 2. Use Restrictions and Permitted Evaluation Use The Software is provided solely for internal testing and evaluation purposes. Licensee shall not use the Software for: production operations; commercial use; customer-facing services; or any live business processes. Permitted Use of Real Data Notwithstanding the foregoing, Licensee may use limited amounts of real or production data solely for internal testing and evaluation purposes, provided that: such use is conducted in a non-production, isolated environment; no live business operations or customer services rely on such use; Licensee applies appropriate safeguards, including data minimization, access controls, and anonymization or masking where feasible; Licensee remains solely responsible for compliance with applicable data protection and privacy laws; and such use is undertaken entirely at Licensee’s own risk. 3. License Restrictions Except as otherwise expressly provided under this Agreement, Licensee shall have no right and specifically agrees not to, and shall not permit third parties to: make error corrections to or otherwise modify or adapt the Software and/or Services or create derivative works based upon the Software and/or Services; decompile, decrypt, reverse engineer, disassemble or otherwise reduce any portion of the Software to human-readable form; grant access to the Software and/or Services to any other person or entity; make any use of the Software and/or Services in whole or in part that is not expressly permitted by the terms of this Agreement or the User Documentation; use any of the Software and/or Services in any manner that will or could damage, disable, overburden or impair or interfere with any other party’s use and enjoyment of the Software and/or Services; attempt to gain unauthorized access to any service, account, computer systems or computer networks associated with the Software and/or Services. The license granted herein does not include Software source code. 4. Availability of the Software Because the Software is provided solely for testing and evaluation, Licensor does not warrant that the Software and/or Services will be available 24 hours per day, 7 days per week. The Licensor has no obligation to restore access, provide technical support, or supply updates if the Software becomes suspended, interrupted, or defective. The Licensor will have no liability to Licensee for the unavailability of the Software and/or Services at any time. In addition, the Licensor reserves the right, in its sole discretion, at any time and without prior notice, to refuse access to the Software and/or Services to any individual, company, institution or other entity. 5. Disclaimer of Warranty THE SOFTWARE AND SERVICES ARE PROVIDED STRICTLY ON AN “AS IS” AND “AS AVAILABLE BASIS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. THE ENTIRE RISK AS TO THE RESULTS AND PERFORMANCE OF THE SOFTWARE AND SERVICES IS ASSUMED FULLY AND EXCLUSIVELY BY LICENSEE. TO THE MAXIMUM EXTENT PERMITTED BY LAW, LICENSOR DISCLAIMS ANY WARRANTIES WITH RESPECT TO THE SOFTWARE AND SERVICES, WHETHER EXPRESS OR IMPLIED, ARISING BY LAW, CUSTOM, PRIOR ORAL OR WRITTEN STATEMENTS, OR OTHERWISE, EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF MERCHANTABILITY, QUALITY AND FITNESS FOR A PARTICULAR PURPOSE. LICENSOR DOES NOT WARRANT THE FUNCTIONS CONTAINED IN THE SOFTWARE AND SERVICES WILL MEET ANY REQUIREMENTS OR NEEDS LICENSEE MAY HAVE, OR THAT THE SOFTWARE AND SERVICES WILL OPERATE ERROR FREE, OR IN AN UNINTERRUPTED FASHION, OR THAT THE SOFTWARE AND SERVICES ARE COMPATIBLE WITH ANY PARTICULAR PLATFORM. FOR THE AVOIDANCE OF DOUBT, THIS LIMITATION OF LIABILITY APPLIES TO ANY USE OF REAL OR PRODUCTION DATA BY LICENSEE AS PERMITTED UNDER SECTION 2 ABOVE. 6. Absolute Limitation of Liability NO LIABILITY. NOTWITHSTANDING ANYTHING HEREIN TO THE CONTRARY, TO THE FULL EXTENT PERMISSIBLE UNDER APPLICABLE LAW, IN NO EVENT SHALL LICENSOR OR ANY OF ITS OFFICERS, DIRECTORS, SHAREHOLDERS, EMPLOYEES, AGENTS, REPRESENTATIVES OR ANY OF ITS THIRD PARTY PROVIDERS (EACH, A “LICENSOR PARTY”), BE LIABLE TO LICENSEE OR ANY OTHER ENTITY IN ANY WAY, SHAPE, OR FORM FOR ANY DAMAGES OR LOSSES ARISING OUT OF THIS AGREEMENT OR THE USE OF THE SOFTWARE. THIS ABSOLUTE LIMITATION APPLIES TO ANY (A) DIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL, INDIRECT OR PUNITIVE DAMAGES, (B) LOST PROFITS, LOST BUSINESS OR LOST OR CORRUPTED DATA, (C) ANY DAMAGES RESULTING FROM LOSS OF USE, OR INTERRUPTION OF BUSINESS, (D) COST OF PROCUREMENT OF SUBSTITUTE SOFTWARE, TECHNOLOGY, GOODS OR SERVICES, OR (E) ANY DAMAGES CAUSED DUE TO THE NEGLIGENT OR IMPROPER USE OF THE SOFTWARE AND/OR SERVICES, IN EACH CASE HOWEVER CAUSED, ON ANY THEORY OF LIABILITY, AND WHETHER OR NOT LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. LICENSEE USES THE SOFTWARE SOLELY AT THEIR OWN RISK. Without limiting the generality of the aforesaid, Licensor shall not be responsible for any damage caused to Licensee in connection with any third-party software (including any open source software) included in the Software, if any. 7. Indemnity LICENSEE AGREES TO FULLY INDEMNIFY, DEFEND AND HOLD HARMLESS THE LICENSOR AND ANY LICENSOR PARTY, FROM AND AGAINST ANY AND ALL CLAIMS, LOSSES, DAMAGES AND EXPENSE (INCLUDING ATTORNEYS’ FEES) ARISING FROM OR RELATED TO THE LICENSEE’S USE OF THE SOFTWARE AND/OR SERVICES, PARTICULARLY ANY USE IN A PRODUCTION ENVIRONMENT IN BREACH OF THIS AGREEMENT. 8. Proprietary Rights The Software, Services and User Documentation are protected by copyright and other intellectual property laws and international treaties. The Software is licensed and not sold, and Licensee will acquire no ownership rights of any kind or nature whatsoever in the Software. The Licensor (or its third-party providers, if any) reserves all rights, including proprietary rights, not expressly and specifically granted to Licensee in this Agreement. Without limiting the foregoing, the Licensor (or its third-party providers, if any) retains all title, right, and interest in and to the Software, Services and the User Documentation, and all enhancements, improvements or other modifications made to or derived from the Software, Services and the User Documentation, including all patches, revisions, service packs and other updates. 9. Trademark and use of Name REGATTA™ is a registered trademark of Licensor. No right, license, or interest to such trademark is granted hereunder, and Licensee agrees that no such right, license, or interest shall be asserted by Licensee with respect to such trademark. Licensee may not use Licensor’s name and/or Software name without Licensor’s prior written consent, other than for the purpose of publishing positive product reviews regarding its use of the Software and/or Services. 10. Ownership and Restrictions Licensor or its licensors retain all ownership and intellectual property rights in the Software. You may not do any of the following: Remove or modify any Software markings or any notice of the Licensor’s or its licensors’ proprietary rights. Make the Software and/or Services available in any manner to any third party. Use the Software and/or Services to provide third party training. Assign this Agreement or give or transfer the Software and/or Services or an interest in them to another individual or entity. Cause or permit reverse engineering (unless required by law for interoperability). Disassembly or decompilation of the Software. Create derivative works based on the Software and/or Services. Disclose results of any Software and/or Services benchmark tests or any other tests without Licensor’s prior written consent. 11. Compliance with Laws Licensee will comply with all applicable laws in performing this Agreement and in connection with any use of the Software and/or Services. Licensee agrees to comply fully with the U.S. and Israeli export laws and to provide Licensor with such documentation, assurances and access to records as may be required to obtain licenses under the U.S. and Israeli export laws. 12. Term And Termination This Agreement is effective until terminated. Because this is a developer and evaluation license, Licensor may terminate this Agreement at any time, for any reason, without notice. Without prejudice to any other rights the Licensor may have, this Agreement will also terminate immediately and automatically if Licensee fails at any time to comply with the terms and conditions set forth herein. Upon termination of this Agreement for any reason, the license granted herein will automatically terminate and Licensee: (i) will cease to have and enjoy any and all rights to use the Software and Services, and (ii) if applicable, will remove the Software or any portion thereof from all hard drives and other storage media and destroy all copies of the Software or any portion thereof in its possession or under its control. Termination or expiration shall not affect provisions that by their nature survive such termination or expiration, including (without limitation) the provisions of the Sections titled “Disclaimer of Warranty”, “Absolute Limitation of Liability”, “Indemnity”, “Proprietary Rights”, “Trademark and use of Name”, “Governing Law; Jurisdiction”, “Severability“, “Assignment“, “Entire Agreement; No Waiver“, “Amendments” and “Third Party Beneficiaries”. 13. Confidentiality Both during the period of the subscription and thereafter, each of Licensor and Licensee undertakes not to reproduce, copy, or disclose to any third party and not use any Confidential Information of the other party, except, in case of Licensor, for purposes of providing the Service and fulfilling its obligations hereunder to Licensee. 14. Governing Law; Jurisdiction This Agreement shall be construed and governed in accordance with the laws of the State of Israel, excluding its conflict of law rules. The exclusive jurisdiction for any disputes arising out of or in connection with this Agreement, shall be appropriate court sitting in Tel Aviv, Israel. 15. Severability Should any term of this Agreement be declared void or unenforceable by any court of competent jurisdiction, such declaration shall have no effect on the remaining terms hereof. 16. Assignment Licensee will not assign this Agreement or any of Licensee’s rights or duties hereunder except with the prior written consent of Licensor, and any attempt to assign the Agreement without such consent will be void. Licensor may freely assign this Agreement. Without derogating from the above, any transferee must agree in writing to be bound by all terms of this Agreement. 17. Entire Agreement; No Waiver This Agreement represents the entire agreement between Licensee and the Licensor, and it supersedes any prior proposal, representation, or understanding between the parties. The failure of either party to enforce any rights granted hereunder or to take action against the other party in the event of any breach hereunder shall not be deemed a waiver by that party as to subsequent enforcement of rights or subsequent actions in the event of future breaches. 18. Amendments No modification, amendment or waiver of any provision of this Agreement shall be effective unless in writing and signed by the duly authorized representative of Licensor. Notwithstanding the above, Licensor shall be entitled to amend and change the terms of this Agreement, and it is the Licensee’s responsibility to check the latest version of this Agreement as shall be published by Licensor at https://regatta.dev/dla. 19. Third Party Beneficiaries Licensor’s licensors and suppliers are third-party beneficiaries to this Agreement and are entitled to the rights and benefits hereunder and may enforce the provisions hereof as if they were a party hereto. --- # Regatta End-User License Agreement Source: https://regatta.dev/eula Updated: 2026-06-11 IMPORTANT – READ CAREFULLY BEFORE DOWNLOADING, INSTALLING OR USING THE REGATTA DATABASE SOFTWARE (THE “SOFTWARE“). NOTE THE TERM “SOFTWARE” AS USED HEREIN SHALL ALSO INCLUDE INTERNET-BASED AND OTHER DATABASE SERVICES PROVIDED BY REGATTA DATA LTD. (“LICENSOR”) THROUGH THE SOFTWARE (THE “SERVICES”), AND ANY PATCHES, UPDATES, MODIFIED VERSIONS, SERVICE PACKS AND UPGRADES WHICH MAY BE PROVIDED BY THE LICENSOR FROM TIME TO TIME (IF ANY)). BY USING THE SOFTWARE AND/OR SERVICES, YOU (“YOU” OR ”LICENSEE”) ACKNOWLEDGE THAT THE LICENSEE HAS READ THIS LICENSE AGREEMENT (“AGREEMENT”), THAT LICENSEE UNDERSTANDS IT, AND IS CONSENTING TO BE BOUND BY AND BECOMING A PARTY TO THIS AGREEMENT. IF LICENSEE DOES NOT AGREE TO ALL OF THE TERMS OF THIS AGREEMENT, LICENSEE SHOULD NOT USE THE SOFTWARE AND/OR SERVICES. FURTHERMORE, BY ACCEPTING THE TERMS OF THIS AGREEMENT, LICENSEE HEREBY WAIVES ANY RIGHTS OR REQUIREMENTS UNDER ANY LAWS OR REGULATIONS IN ANY JURISDICTION WHICH REQUIRE AN ORIGINAL (NON-ELECTRONIC) SIGNATURE OR DELIVERY OR RETENTION OF NON-ELECTRONIC RECORDS, TO THE MAXIMUM EXTENT PERMITTED UNDER APPLICABLE LAW. IN ADDITION, LICENSEE HEREBY ACKNOWLEDGES THAT IT IS FAMILIAR WITH, HAS CAREFULLY READ, UNDERSTOOD AND AGREES TO THE TERMS OF THE LICENSOR’S DATA PROCESSING AGREEMENT AVAILABLE AT regatta.dev (“DPA”). IF YOU ARE NOT THE LICENSEE AND YOU INSTALL THIS SOFTWARE AND/OR USE THE SERVICES ON BEHALF OF THE LICENSEE, YOU WARRANT AND REPRESENT THAT YOU ARE AUTHORIZED TO ACT ON BEHALF OF THE LICENSEE AND TO ACCEPT AND BIND THE LICENSEE TO THE TERMS OF THIS AGREEMENT AND THE DPA. 1. License Grant. Subject to and conditioned upon Licensee’s compliance with the terms and conditions of this Agreement and the DPA, Licensor hereby grants to Licensee, and Licensee accepts, a limited, nonexclusive, nontransferable license to use the Software (in machine-readable, object code form only) and the Services, for the sole purposes for which the Software is provided to Licensee by the Licensor and subject to any use restrictions that may be applicable to such use, pursuant to the accompanying documentation for the Software made available by Licensor to Licensee from time to time (“User Documentation”). Licensee agrees not to assign, sublicense, transfer, pledge, lease, rent, or share Licensee’s rights under this Agreement and the DPA. Except as specifically authorized under this paragraph, no copies of the Software or any portions thereof may be made by Licensee or any person under Licensee’s authority or control. 2. License Restrictions. Except as otherwise expressly provided under this Agreement, Licensee shall have no right and specifically agrees not to, and shall not permit third parties to: (i) make error corrections to or otherwise modify or adapt the Software and/or Services or create derivative works based upon the Software and/or Services; (ii) decompile, decrypt, reverse engineer, disassemble or otherwise reduce any portion of the Software to human readable form; (iii) grant access to the Software and/or Services to any other person or entity; (iv) make any use of the Software and/or Services in whole or in part that is not expressly permitted by the terms of this Agreement or the User Documentation; (v) use any of the Software and/or Services in any manner that will or could damage, disable, overburden or impair or interfere with any other party’s use and enjoyment of the Software and/or Services; and (vi) attempt to gain unauthorized access to any service, account, computer systems or computer networks associated with the Software and/or Services. The license granted herein does not include Software source code. 3. Availability of the Software. Licensor does not warrant that the Software and/or Services will be available 24 hours per day, 7 days per week. If Licensee’s access to the Software and/or Services is suspended or interrupted or a fault or defect occurs which prevents Licensee’s access to the Software and/or Services, the Licensor will attempt to restore access to the Software and Services (to the extent determined solely by the Licensor in its discretion). The Licensor will have no liability to Licensee for the unavailability of the Software and/or Services at any time. In addition, the Licensor reserves the right, in its sole discretion, at any time and without prior notice, to refuse access to the Software and/or Services to any individual, company, institution or other entity in violation of the terms of this Agreement. 4. Disclaimer of Warranty. THE SOFTWARE AND SERVICES ARE PROVIDED “AS IS” AND “AS AVAILABLE BASIS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. THE ENTIRE RISK AS TO THE RESULTS AND PERFORMANCE OF THE SOFTWARE AND SERVICES IS ASSUMED FULLY AND EXCLUSIVELY BY LICENSEE. TO THE MAXIMUM EXTENT PERMITTED BY LAW, LICENSOR DISCLAIMS ANY WARRANTIES WITH RESPECT TO THE SOFTWARE AND SERVICES, WHETHER EXPRESS OR IMPLIED, ARISING BY LAW, CUSTOM, PRIOR ORAL OR WRITTEN STATEMENTS, OR OTHERWISE, EITHER EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF MERCHANTABILITY, QUALITY AND FITNESS FOR A PARTICULAR PURPOSE. LICENSOR DOES NOT WARRANT THE FUNCTIONS CONTAINED IN THE SOFTWARE AND SERVICES WILL MEET ANY REQUIREMENTS OR NEEDS LICENSEE MAY HAVE, OR THAT THE SOFTWARE AND SERVICES WILL OPERATE ERROR FREE, OR IN AN UNINTERRUPTED FASHION, OR THAT THE SOFTWARE AND SERVICES ARE COMPATIBLE WITH ANY PARTICULAR PLATFORM. IN PARTICULAR, LICENSOR DOES NOT REPRESENT OR WARRANT TO LICENSEE THAT THE USE OF THE SOFTWARE AND SERVICES WILL MEET LICENSEE’S REQUIREMENTS. 5. Limitation of Liability. NOTWITHSTANDING ANYTHING HEREIN TO THE CONTRARY, TO THE FULL EXTENT PERMISSIBLE UNDER APPLICABLE LAW, IN NO EVENT SHALL LICENSOR OR ANY OF ITS OFFICERS, DIRECTORS, SHAREHOLDERS, EMPLOYEES, AGENTS, REPRESENTATIVES OR ANY OF ITS THIRD PARTY PROVIDERS (EACH, A “LICENSOR PARTY”), BE LIABLE TO LICENSEE OR ANY OTHER ENTITY FOR ANY (A) SPECIAL, CONSEQUENTIAL, INCIDENTAL, INDIRECT OR PUNITIVE, DAMAGES, (B) LOST PROFITS, LOST BUSINESS OR LOST OR CORRUPTED DATA, (C) ANY DAMAGES RESULTING FROM LOSS OR USE, OR INTERRUPTION OF BUSINESS, (D) COST OF PROCUREMENT OF SUBSTITUTE SOFTWARE, TECHNOLOGY, GOODS OR SERVICES, OR (E) ANY DAMAGES CAUSED DUE TO THE NEGLIGENT OR IMPROPER USE OF THE SOFTWARE AND/OR SERVICES, IN EACH CASE HOWEVER CAUSED, ON ANY THEORY OF LIABILITY, AND WHETHER OR NOT LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS SHALL APPLY NOTWITHSTANDING ANY FAILURE OF ESSENTIAL PURPOSE OF ANY LIMITED REMEDY. IN ADDITION, LICENSOR’S CUMULATIVE LIABILITY TO LICENSEE OR ANY OTHER PARTY FOR ANY LOSS OR DAMAGES RESULTING FROM ANY CLAIMS, DEMANDS, OR ACTIONS ARISING OUT OF OR RELATING TO THIS AGREEMENT AND THE DPA SHALL NOT EXCEED THE LICENSE FEE PAID BY LICENSEE TO LICENSOR FOR THE USE OF THE SOFTWARE AND SERVICES DURING THE TWELVE (12) MONTHS PRECEDING THE CLAIM. THE EXISTENCE OF MORE THAN ONE CLAIM OR SUIT WILL NOT ENLARGE OR EXTEND THESE LIMITATIONS AND THE REMEDIES SET FORTH HEREIN, AND THE SAME SHALL CONSTITUTE LICENSOR’S SOLE AND EXCLUSIVE REMEDIES FOR ANY CLAIM FOR DAMAGES ARISING IN ANY WAY OUT OF THIS AGREEMENT AND THE DPA. IF LICENSEE IS SUBJECT TO A JURISDICTION IN WHICH ANY OF THE DISCLAIMERS OR LIMITATIONS OF LIABILITY HEREIN IS NOT VALID, LICENSEE AGREES TO BE BOUND BY THE SAME TO THE MAXIMUM EXTENT PERMITTED BY SUCH LAW OR REGULATIONS. IN NO EVENT SHALL LICENSOR’S THIRD PARTY LICENSORS AND SUPPLIERS WILL BE LIABLE TO LICENSEE OR ANY OTHER ENTITY FOR ANY DAMAGE OF ANY KIND HOWEVER CAUSED, ON ANY THEORY OF LIABILITY. Without limiting the generality of the aforesaid, Licensor shall not be responsible to any damage caused to Licensee in connection with of any third party software (including any open source software) included in the Software, if any. 6. Indemnity. LICENSEE AGREES TO FULLY INDEMNIFY, DEFEND AND HOLD HARMLESS THE LICENSOR AND ANY LICENSOR PARTY, FROM AND AGAINST ANY AND ALL CLAIMS, LOSSES, DAMAGES AND EXPENSE (INCLUDING ATTORNEYS’ FEES) ARISING FROM OR RELATED TO THE LICENSEE’S USE OF THE SOFTWARE AND/OR SERVICES. 7. Proprietary rights. The Software, Services and User Documentation are protected by copyright and other intellectual property laws and international treaties. The Software is licensed and not sold, and Licensee will acquire no ownership rights of any kind or nature whatsoever in the Software. The Licensor (or its third-party providers, if any) reserves all rights, including proprietary rights, not expressly and specifically granted to Licensee in this Agreement. Without limiting the foregoing, the Licensor (or its third party providers, if any) retains all title, right, and interest in and to the Software, Services and the User Documentation, and all enhancements, improvements or other modifications made to or derived from the Software, Services and the User Documentation, including all patches, revisions, service packs and other updates (even if made based, in whole or in part, on input and/or requests of Licensee). The proprietary rights reserved hereby include, without limitation, all patents, patent applications, copyrights, trademarks, service marks, know-how, source codes and any and all other applicable intellectual property rights and interests in and to the Software, Services and the User Documentation, and all enhancements, improvements or other modifications made to or derived therefrom. 8. Trademark and use of Name. REGATTA™ is a registered trademark of Licensor. No right, license, or interest to such trademark is granted hereunder, and Licensee agrees that no such right, license, or interest shall be asserted by Licensee with respect to such trademark.  Licensee may not use Licensor’s name and/or Software name without Licensor’s prior written consent, other than for the purpose of publishing positive product reviews regarding its use of the Software and/or Services. 9. Ownership and Restrictions. Licensor or its licensors retain all ownership and intellectual property rights in the Software. You may not do any of the following: Remove or modify any Software markings or any notice of the Licensor’s or its licensors’ proprietary rights. Make the Software and/or Services available in any manner to any third party Use the Software and/or Services to provide third party training Assign this Agreement or give or transfer the Software and/or Services or an interest in them to another individual or entity Cause or permit reverse engineering (unless required by law for interoperability) Disassembly or decompilation of the Software (the foregoing prohibition includes but is not limited to review of data structures or similar materials produced by Software) Create derivative works based on the Software and/or Services Disclose results of any Software and/or Services benchmark tests or any other tests without Licensor’s prior written consent 10. Compliance with Laws. Licensee will comply with all applicable laws in performing this Agreement and in connection with any use of the Software and/or Services. Licensee agrees to comply fully with the U.S. and Israeli export laws and to provide Licensor with such documentation, assurances and access to records as may be required to obtain licenses under the U.S. and Israeli export laws.  11. Term And Termination. Unless earlier terminated as provided herein, any license for the use of the Software and Services shall be valid for the limited period specified in writing by the Licensor, unless earlier terminated as provide in this Agreement. Without prejudice to any other rights the Licensor may have, including available legal remedies, this Agreement will terminate immediately and automatically if Licensee fails at any time to comply with the terms and conditions set forth herein. In addition, each of Licensor and Licensee shall be entitled to terminate this Agreement in case of a breach by the other party which is not curable, or, if curable, is not cured by the other party within 14 days from receipt of the first party’s written notice thereof. Licensor shall be entitled to suspend the use of the Software and/or Services or any portion thereof during the time such breach by Licensee has occurred and has not yet been cured. In case of termination by Licensee for breach by Licensor, Licensor shall refund Licensee a proportionate amount of the basic license fees pre-paid by Licensee (if any) applicable to the remaining portion of the term following the effective date of termination. In all other events of termination Licensee shall not be entitled to any refund. Upon termination of this Agreement for any reason, the license granted herein will automatically terminate and Licensee: (i) will cease to have and enjoy any and all rights to use the Software and Services, and (ii) if applicable, will remove the Software or any portion thereof from all hard drives and other storage media and destroy all copies of the Software or any portion thereof in its possession or under its control. Termination or expiration of the Subscription Agreement shall not affect provisions that by their nature survive such termination or expiration, including (without limitation) the provisions of the Sections of this Agreement titled “Disclaimer of Warranty”, “Limitation of Liability”, “Indemnity”, “Proprietary Rights”, “Trademark and use of Name”, “Governing Law; Jurisdiction”, “Severability“, “Assignment“, “Entire Agreement; No Waiver“, “Amendments” and “Third Party Beneficiaries”. 12. Confidentiality. Both during the period of the subscription and thereafter, each of Licensor and Licensee undertakes not to reproduce, copy, or disclose to any third party and not use any Confidential Information of the other party, except, in case of Licensor, for purposes of providing the Service and fulfilling its obligations hereunder to Licensee. Each of Licensor and Licensee shall maintain the confidentiality of the other party’s Confidential Information with the same degree of care as it maintains its own Confidential Information, but in no case less than reasonable care. “Confidential Information” means any information identified as “confidential” or “proprietary,” either by legend on written or electronically stored material, or which ought reasonably to be recognized as confidential or proprietary by virtue of its nature or the circumstances of its disclosure. The foregoing will not be considered as Confidential Information of a party: (a) information already known to the other party without an obligation of confidentiality, (b) information that is or becomes publicly known other than through a breach by the receiving party, or (c) information that is independently developed by the receiving party or its affiliates. If a party is compelled by law or administrative action to disclose the other party’s confidential information, such party shall provide the other party with a prior notice of such compelled disclosure (to the extent legally permitted) and reasonable assistance, at the other party’s expense, if the other party wishes to contest the disclosure. Each of Licensor and Licensee shall implement reasonable security measures to protect the Confidential Information of the other party. 13. Governing Law; Jurisdiction. This Agreement shall be construed and governed in accordance with the laws of the State of Israel, excluding its conflict of law rules. The exclusive jurisdiction for any disputes arising out of or in connection with this Agreement, shall be appropriate court sitting in Tel Aviv, Israel.  14. Severability. Should any term of this Agreement be declared void or unenforceable by any court of competent jurisdiction, such declaration shall have no effect on the remaining terms hereof.  15. Assignment. Licensee will not assign this Agreement or any of Licensee’s rights or duties hereunder except with the prior written consent of Licensor, and any attempt to assign the Agreement without such consent will be void. Licensor may freely assign this Agreement. Without derogating from the above, any transferee must agree in writing to be bound by all terms of this Agreement. 16. Entire Agreement; No Waiver. This Agreement and the DPA represent the entire agreement between Licensee and the Licensor, and it supersedes any prior proposal, representation, or understanding between the parties. The failure of either party to enforce any rights granted hereunder or to take action against the other party in the event of any breach hereunder shall not be deemed a waiver by that party as to subsequent enforcement of rights or subsequent actions in the event of future breaches.  17. Amendments. No modification, amendment or waiver of any provision of this Agreement shall be effective unless in writing and signed by the duly authorized representative of Licensor. Notwithstanding the above, Licensor shall be entitled to amend and change the terms of this Agreement and it is the Licensee’s responsibility to check the latest version of this Agreement as shall be published by Licensor at regatta.dev/eula. Licensee is advised to review these terms of the Agreement regularly for any changes. Licensee’s continued use of the Software and/or Services will be deemed as acceptance to amended or updated terms. 18. Third Party Beneficiaries. Licensor’s licensors and suppliers are third-party beneficiaries to this Agreement and are entitled to the rights and benefits hereunder and may enforce the provisions hereof as if they were a party hereto. --- # Get Started for [[Free]] Source: https://regatta.dev/get-started Updated: 2026-08-17 Create your Regatta Cloud account --- # Regatta 2026 Homepage Source: https://regatta.dev/ Updated: 2026-08-19 The distributed database for high-performance transactional, analytical, and agentic AI workloads. --- # Press & Analysts Source: https://regatta.dev/press-analysts Updated: 2026-08-17 RegattaDB press coverage and analyst reports on its scale-out architecture and unified OLTP, OLAP, and vector database for AI agents. --- # Privacy Policy Source: https://regatta.dev/privacy-policy Updated: 2026-05-04 This privacy policy describes how we, at Regatta (“Regatta”, “we”, “our” or “us”), collect and process personal information related to you when you visit our website (“Website”) and the rights and options available to you. Personal Information that We Collect and Use We receive and store any information you enter on the Website or give us in any other way. Hence, we collect and use the following personal information related to you: When you fill in any form on the Website or send us a message through the chat, you provide us with your full name, address, phone number, email address, company name, job position or title and any additional information that you choose to provide us. Traffic and online usage information that your online activities generate and are being recorded by certain tracking technologies, such as cookies. Such information has a potential to be identifiable information, such as IP address, MAC address, device type, operating system, browser information, clicks, session duration, content viewing, content downloading, etc. related to you. We will collect such information from each of the Website’s visitors. What Do We Do with Personal Information Related to You? We use the personal information we collect and receive to provide you with our content and to manage our communication with you, to enable the Website’s tools and features, to study and analyze the functionality of the Website and your activities, to provide support, to measure the Website activity, to maintain the Website, to make it better and to continue developing it. We will further use personal information related to you to provide you with commercial and marketing information about Regatta and our related products or other content. We will use personal information related to you to enforce our Website’s Terms of Use, policies and legal agreements, to comply with court orders and warrants, and assist law enforcement agencies, prevent fraud, misappropriation, infringements, identity thefts and any other misuse of the Website, and to take any action in any legal dispute and proceeding. How We Share Personal Information Related to You? We do not sell, rent, lease, or otherwise provide personal information to third parties, except as provided below: We will share personal information related to you with third party service providers, to help us operate, manage and protect the Website and our operations. These service providers provide us with services such as analytics, mailing services, data storage, etc. We will disclose personal information related to you with or without notice (a) if required by a subpoena or other judicial or administrative order; (b) where required by law; or (c) at our sole discretion, where we deem it necessary to protect the safety of any individual, the general public, or to prevent violations of our, or of any third party’s rights. We will disclose personal information related to you in case of a merger, acquisition or any other structural change that will require us to do so as part of the structural change. Choice You are not required by law to provide us with the personal information described above. At any time, you may opt out of our newsletter and marketing mailing lists or mobile phones lists, or request that personal information related to you will not be shared with our third-party service providers and business partners, as described above. It will take up to 30 days from the moment that we receive your request to take effect. Note that we may keep your details without using them if necessary, and for the necessary period of time, for legal requirements and proceedings. For further information, please read the ‘Data Retention’ section in this policy. Please contact us at: info@regatta.dev to exercise your choices. Accessing Personal Information Related to You If you assume that personal information related to you is inaccurate, incomplete or not up to date, please provide us with the necessary information to correct it. At any time, you can contact us at: info@regatta.dev and request to access the personal information related to you that we keep. We will ask you to provide us with certain credentials to verify your identity, and to the extent required under applicable law, we will make good-faith efforts to locate the personal information that you request to access. Data Retention We will retain personal information related to you for as long as necessary to fulfill the purposes of using such personal information under this policy or as permitted by law. We will keep aggregated non-identifiable information without limitation, and to the extent reasonable, we will delete or de-identify potentially identifiable information when we no longer need to process the information in an identifiable form. Transfer of Personal Information Outside Your Territory We will store and process personal information in various sites throughout the globe. If you are a resident in a jurisdiction where transfer of personal information related to you outside of your territory requires your consent, then you provide us with your freely given, expressed, specific and unambiguous consent for such transfer. Cookies and Trackers Cookies are small files that a web server sends to a user’s device when the user browses online. Your device removes session cookies when you close your browser session, but persistent cookies last for longer periods. You can view the expiry date of each cookie through your browser settings. We use both session and persistent cookies on our Website. From time to time we will use session and persistent cookies and other web-tracking technologies, such as pixel tags and local storage objects, to facilitate the use of the Website’s features and tools and to improve visitors’ experience with our Website. Every browser allows you to manage your cookies preferences. You can block or remove certain or all cookies through your browser settings. Please bear in mind that blocking or removing cookies may impact your user experience with the Website. Please note that disabling or blocking cookies will affect your ability to use the Website. Aggregated and Analytical Information We use standard analytics tools. For example, we use Google Analytics to learn about how you and others use the Website, how we should improve your user experience and which improvements we should prioritize. We will use additional or other analytical tools from time to time. The privacy practices of these tools are subject to their own privacy policies and they use their own cookies to provide their services. You can find more information about how Google uses data when you use the Website at: www.google.com/policies/privacy/partners/. We use anonymous, statistical or aggregated information and will share it with our partners for legitimate business purposes. It has no effect on your privacy, because there is no reasonable way to extract data from the aggregated information that we or others can associate specifically to you. We will share personal information related to you only subject to the terms of this policy, or subject to your prior consent. Information Security We maintain the confidentiality of personal information related to you and take reasonable steps to ensure that the information is accurate, complete, current and reliable for its intended use. We take reasonable measures to protect personal information related to you from loss, misuse and unauthorized access, disclosure, alteration and destruction. We do not guarantee that the Website is immune from cyberattacks, malicious activities, malfunctions, honest mistakes or other types of abuse and misuse of personal information. Changes to this Privacy Policy From time to time, we will need to update this policy. If the updates have minor or no consequences, they will take effect 7 days after we post a notice on the Website. Substantial changes will take effect 30 days after we initially post our notice. If we need to adapt this policy to legal requirements, the new policy will become effective immediately or as required. Continuing visiting the Website after the new policy takes effect means that you agree to the new policy. Contact Us If you have any questions or concerns about the way that we process personal information related to you, please email us at: info@regatta.dev. We will review your query and make a good-faith effort to respond promptly. --- # Terms of Service Source: https://regatta.dev/terms-of-service Updated: 2026-05-04 We, Regatta (“Regatta”, “we”, “our”, “us”), own and operate the Regatta website available at: (“Website”). Please read carefully the following terms and conditions, (“Terms”), because they constitute a binding agreement between you and us. By accepting these Terms or by accessing or using the Website, you signify your agreement with these Terms. If you do not agree to these Terms, you may not access or use the Website. Grant of Right We hereby grant you a non-exclusive, non-transferable, limited, personal, revocable right to access the Website, subject to the Terms herein. Notwithstanding any remedies that may be available to us under any applicable law, we may temporarily or permanently deny, limit, or suspend your access to the Website, if we determine, in our sole discretion that: (a) You have abused your rights to use the Website; (b) You have breached the Terms, or any usage guidelines we may convey to you; (c) You have violated any applicable law, rule, or regulation; or (d) You have performed any act or omission which is harmful or likely to be harmful to us, or any other third party, including other users of the Website. Acceptable Use of the Website You may not publish details and content from the Website in other websites or other media platforms in any form. Do not copy content of the Website, embed it in other websites, display it using framing techniques, create mirroring websites, sell, grant a license to use, rent, lend or distribute the Website’s content in any way. Do not link content of the Website separately from the webpage where the content is originally located. When linking to webpages of the Website, no information should be hidden, blocked, modified or deleted from the webpages of the Website. The Website and the content within may not be accessed in order to develop or create a similar or competing Website, including by collecting information from the Website. The Website may not be used for purposes of examination, scanning, scraping, hacking including hacking the Website security systems or any other computer and communication systems serving it, interfering with the Website’s operations, manipulating the Website’s activities, systematic access to the Website’s systems using automated software tools, such as ‘bots’ and ‘crawlers’, and access to the features or functionalities of the Website that are not intended to be accessible or that are not documented. You must not misuse the Website by knowingly introducing viruses, trojans, worms, logic bombs or other material which is malicious or technologically harmful. You must not attempt to gain unauthorized access to the Website, the server on which it is stored, or any server, computer or database connected to it. The Website may not be used for any activity that constitutes or encourages the commission of criminal offense or civil wrong or violates applicable laws, including laws in connection with deception, fraud, forgery, privacy protection, identity theft, viruses and other malicious software distribution, right to publicity, slander, harassment and obscene publications. Do not add links from illegal sites to the Website, including gambling sites, pornography, and enmity sites. Privacy and Data protection We use and process personal information related to you according to our privacy policy. Links The Website may contain links to other websites, information or content provided by third parties. We do not operate or monitor these third-party websites and content. You may find them, or the information and content posted therein, not compatible with your requirements, objectionable, annoying, improper, unlawful or immoral. By linking to a certain website, we do not endorse, or sponsor its content, or confirm its accuracy, credibility, authenticity, reliability, validity, integrity, or legality. We assume no responsibility for such third-party websites or content, or their availability or for any transactions made between you and such third-party websites. We will not be liable, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with your use of or reliance on any such content, goods or services available on or through any third-party websites or content. Intellectual Property The Website includes user interfaces, graphic designs, illustrations, texts, icons, software code and more. All the above are protected by copyright and through additional intellectual property rights. All rights to the Website’s contents (except for content provided by you via the Website’s forms or chat) are owned by us or we have received permission from the owners to use such content on the Website. You may not: (i) reverse engineer, disassemble, decompile, decode or otherwise attempt to derive or gain access to the source code of the Website; or (ii) remove, delete, alter or obscure any trademarks or any copyright, trademark, patent or other intellectual property or proprietary rights notices from the Website. Regatta’s trademarks (whether registered or not), name, logo and domain name – are our sole property. You may not use them, or any confusingly similar mark or text, without our prior express written consent. Information Security Regatta and its hosting Website implement systems, applications and procedures to secure your use of the Website and to minimize the risks of theft, damage, loss of information, or unauthorized access or use of information. However, although we make such efforts, we cannot guarantee that our systems will be immune from any wrongdoings, malfunctions, unlawful interceptions or access, or other kinds of abuse and misuse. Warranty and Limitation of Liability Your use of the Website and your exposure to information on the Website, is at your own risk. We do not take any responsibility for the activity on the Website, and we do not provide any guarantees with respect to the contents contained therein. We do not provide any warranty whatsoever, on behalf of any third party, and it is hereby made explicitly clear that we will not be held responsible for any acts or omissions on the part of any third party. Under no circumstances and under no legal theory, tort, contract, or otherwise, will we be liable to you or any other person for any indirect, special, incidental, punitive, exemplary or consequential damages of any type including, without limitation, loss of data, loss of goodwill, business interruption, computer failure or malfunction, loss of business information, and all other commercial damages or losses even if we have been informed of the possibility of such damages, or for any claim by any other party. You will be responsible for all acts and omissions associated with your use of the Website, including use thereof by any other third party on your behalf or at your permission. We will make efforts to run the Website efficiently and accessible at all times. However, the Website’s operation is dependent upon various factors such as software, hardware and communication networks. By their nature, these factors are not fault free. We do not warrant that the Website will operate in an uninterrupted or error-free manner, or that it will always be available, free from all harmful components, or that at all times it will be completely safe, and secured from unauthorized access to our computers, immune from damages, free of malfunctions, bugs or failures, including, but not limited to, hardware failures, software failures and software communication failures, originating either in us or any other service provider. Such incidents will not be considered a breach of these Terms. We may from time to time change the Website’s structure, layout, design or display, as well as the scope and availability of the information and content therein, without giving any prior notice. Changes of this character by its very nature are likely to result in glitches or cause inconvenience. We will not be held responsible for any outcome of these changes, and failures resulting from them. General We may change these Terms to meet technical, operational and legal changes. We will post a notice about changes made to these Terms on the Website, and by continuing your use of the Website after the new changes have taken effect, you indicate your agreement to the amended Terms. No waiver, concession, extension, representation, alteration, addition or derogation from these Terms will be effective unless provided in writing and expressly. If any provision of these Terms is held by a court of competent jurisdiction to be illegal, invalid, unenforceable, or otherwise contrary to law, the remaining provisions of these Terms will remain in full force and effect. --- # Use Cases Source: https://regatta.dev/use-cases Updated: 2026-06-24 Workloads where OLTP, OLAP, and vector must operate together within a single transaction or agent loop. Separating them across systems doesn't add friction , it... --- # When Rows Outgrow the Page: RegattaDB vs. PostgreSQL TOAST Source: https://regatta.dev/blog/pvr-toast Updated: 2026-09-15 Author: Erez Webman ## TL;DR Agentic AI workloads often push row size and update volume into this territory as a matter of course. That's where slotted pages start to cost the database. Large rows break slotted pages. We tested rows just over a page (~10KB) against PostgreSQL's TOAST and RegattaDB's log-structured row store. - RegattaDB inserted rows 8.6x faster. - On a fresh table, RegattaDB full-scanned 2.7x faster. - After 1.2 billion point-updates,PostgreSQL's scan was 25x slower than RegattaDB. RegattaDB's scan time held flat past 2.4 billion updates. ## Introduction Agentic AI needs a database that handles large, varied data at scale, with real serializability and sustained performance as agents keep writing. RegattaDB was built for that. Its scale-out design grows to thousands of nodes without giving up performance or efficiency on small deployments, down to a single node. What does a row look like in an agentic workload? A single agent turn can carry a tool-call trace, retrieved context passages, one or more embeddings, and running conversation state, often serialized together as one row. As they work within context, they can easily expand row size well beyond what typical humans can decipher or reason. Agentic AI, as well as modern applications, use row sizes that can easily land past a few KB, and well into the range where slotted pages start needing an overflow strategy. And unlike a typical OLTP row that's written once and read many times, agent state gets revised repeatedly as a task runs: append a step, update a status, patch in a new tool result. High row size and high update churn, together, on the same row. That combination is exactly what this experiment isolates. ## Background We built RegattaDB for performance, performance at scale, and performance efficiency. Its scale-out design enables RegattaDB to grow to thousands of nodes in a cluster, without compromising the performance or efficiency of small configurations – not even of single-node ones. ### Data Layouts and Storage I/O Performance Matter Storage I/O performance has a major effect on the overall performance of the database. The performance of the underlying disks (e.g., SSDs) does matter, no doubt about that. However, the data layouts used by the database have a cardinal impact over the database performance. I’m using the term Data Layout to describe the persistent data-structures as well as the corresponding mechanisms used by the database. The data layout, and the entire “storage-engine” of the database dictate how much (read and write) disk I/O amplification takes place, whether the underlying disks are accessed in ways that resonate well with their performance characteristics, and whether the database can leverage or even saturate the underlying disks. ### About The Slotted Pages Data Layout Many traditional relational databases use variations of the Slotted Pages data layout to store table rows. The slotted pages data layout performs reasonably well for small rows, especially fixed-size ones. When rows are larger, change in size, or the table shrinks, the slotted pages approach becomes inefficient. One of the main problems with slotted pages is related to how the database handles rows that are larger than a page. For many databases the size of a page is pretty limited, e.g., 8KB, due to architectural reasons that are outside the scope of this discussion. Slotted pages based relational databases use various strategies to fight that fundamental problem. Some databases use the concept of “overflow pages”, or variations of such strategies – e.g., PostgreSQL’s TOAST, which I’ll cover shortly… Those strategies unavoidably degrade storage I/O performance as they lead to disk I/O amplifications, yet are essential to enable handling of larger rows. Unfortunately, modern data often needs rows that are larger than the typical slotted page size. ### RegattaDB’s Modular Data Layout Architecture As mentioned in theRegattaDB Architecture blog (https://regatta.dev/blog/regatta-s-architecture-a-bird-s-eye-view), RegattaDB has a modular data layout architecture, allowing various layouts to optimally support different data and access patterns. It was important for us to design a data layout that would work well with modern data and media. RegattaDB’s first row-store data layout is specifically optimized for flash media. It allows us to optimally support both traditional small-rows-with-more-or-less-fixed-size, and variable-sized-large-rows-with-a-large-dynamic-range-of-sizes (all within the same table). Since traditional slotted pages were not an ideal fit for that purpose, we developed our own log-structured data layout. This data layout is optimal for a large variety of workload types. > Note: We chose not to use the common log-structured merge tree (LSM tree) approach, since some properties of LSM trees don’t always align well with flash media or certain types of workloads. RegattaDB’s log-structure data layout operates very differently from LSM tree. > Note: As an additional disk I/O performance optimization, RegattaDB implements its own data layouts directly on raw block storage, bypassing the filesystem and the I/O overheads it would otherwise introduce. ## Planning a Comparison between RegattaDB’s Data Layout and PostgreSQL’s Slotted Pages We conducted a comparative experiment between RegattaDB and PostgreSQL to demonstrate the performance differences between RegattaDB’s data layout and a slotted pages data layout when handling rows that span more than a page. Specifically, we looked at PostgreSQL’s slotted pages implementation. In this blog we will describe the experiment and share some performance results. Even though RegattaDB is a distributed database that was designed for large scale, we will still compare only a single node of RegattaDB against a (single-node) PostgreSQL. ### Guiding Principles To get meaningful, fair and reliable comparison results, we obeyed the following guiding principles: - Measure performance over time:The performance of data layouts may change over time. It is common that a data layout starts its life providing a certain performance envelope, and that performance degrades the more data and/or more operations on the data take place. How a data layout “ages” is a very important attribute, sometimes overlooked by too short experiments. - Minimize read cache effect:Data layout and the related disk I/O performance are all about interactions with data on-disk. In-RAM cached data may have a blurring effect on such measurements, as when accessing data that’s cached in RAM, the data layout “penalty” is bypassed. Don’t get me wrong, in-RAM read cache has an important impact on database performance, although its effect often diminishes in workloads that use large-enough on-disk working-sets. RegattaDB uses a unique “logical” caching for its read cache that may result in much more effective caching than the usual “physical” page caching approaches used by most other databases around. However, we wanted to completely neutralize those effects, and focus on the data layout and storage part of the house. This could be achieved by various techniques, such as (1) decreasing the read cache size, and/or (2) enlarging the dataset size, and/or (3) coming up with experiments that naturally negate the read cache effect. In our experiments we chose a combination of (1) and (3), mainly to speed up the experiments. - Minimize computations, network, etc.:Excessive computations or network traffic might also have a blurring effect on the measurements. Therefore, the comparative experiment should attempt to minimize those as much as possible. - Be fair:Reasonably optimize PostgreSQL: We started with the recommended PGTune settings as a baseline. Then we further optimized the PostgreSQL configuration and tuning for even better performance. Additionally, whenever any of the databases had a different recommended method of doing something, we complied with that database’s own optimal approach. - Maintain ACID:The experiment should comply with real life scenario constraints. Therefore, we want to maintain full ACID. ### The Experiment, at a High-Level We wanted to conduct a reasonably simple experiment: 1. Preparation:Create a simple schema, with a single table of rows that are a bit larger than a slotted page (e.g., ~10KB). 1. Insertion phase:Insert a large-enough number of rows (but not amazingly large – e.g., 30 million). 1. Post-insertion full scan phase:Initiate a full scan that will need to access sufficient parts of the row. It should be light on computation and light on the “data returned to the client” (to minimize computations and network – see guiding principles above). Measure how long the full scan takes, how much the underlying disk is utilized, etc. 1. Update phase:Start a lengthy period of random updates to those rows. 1. Stop:Stop the updates, and wait for any background tasks (e.g., VACUUM) to complete. 1. Post-update full scan phase:Repeat the same full scan as in step (3). Measure how long it takes, how much the underlying disk is utilized, etc. We mainly wanted to measure the full scan performance (steps 3 and 6), but we couldn’t resist the temptation, and had an eye on the performance of other stages of the experiment as well… We used a bare-metal server and a 1.5 TB NVME SSD, capable of serving a sustained ~5-6 GB/s read workload and ~2 GB/s (or slightly less) write workload. That disk was dedicated to the database, as there was a separate disk for the operating system. We allocated identical servers to PostgreSQL and to RegattaDB. > Note:We also switched between the servers, from time to time, ensuring both servers perform the same. For both databases, we limited the execution to a single NUMA domain (out of two) to avoid any unwanted side effects. For the server running PostgreSQL, we used PostgreSQL 18.3, running on a Red Hat Linux 8. The filesystem was XFS, with configuration options optimized specifically for PostgreSQL. Nothing fancy. We did limit the cache PostgreSQL can see to ~8 GB (we should remember that PostgreSQL also leverages the file-system cache so this should be incorporated as well). Limiting the cache of RegattaDB is even simpler as it does not use any file-system cache (not explicitly and not implicitly). RegattaDB was installed on an identical server (and single NUMA, same OS, etc.), except that the (identical) disk was not formatted with a filesystem since RegattaDB uses raw block storage. To make things simple, we configured a table with 20 varchar columns of roughly 500 bytes each. We also configured a means (e.g., a 64 bit primary key) to uniquely identify a row during the update phase. For the workload generation, we used a home-grown Python program for both PostgreSQL and RegattaDB. The program differs only at its bottom layer: For PostgreSQL it uses the asyncpg python library that provides high performance asynchronous processing. For RegattaDB it uses RegattaDB’s pyregatta library that links with RegattaDB’s low-level connector. To avoid network bottlenecks we located the program in the same server as the database. We ensured that the workload generator is efficient and would not consume resources from the database itself. We monitored that closely during all stages of the experiment, for both PostgreSQL and RegattaDB. ### About PostgreSQL’s TOAST When a row is larger than a page (8KB), PostgreSQL stores some cells of the row in the “table file” (called Heap File in PostgreSQL’s terminology) and stores the remaining cells in a separate file called the TOAST File. Those cells will be denoted here as the TOASTED Cells. That’s PostgreSQL’s variation of how to handle the “slotted page overflow”. ## The Insertion Phase Following the initial setup, the first step was to insert 30 million rows into the table. To be honest, we originally thought this would be a “utilitarian” step: After all, to conduct a full scan (which was “our goal”) we needed to have rows to scan, which is nothing to write home about… We expected both databases to be able to perform the insertion quickly and efficiently. However, we quickly realized that there is a surprising difference between RegattaDB and PostgreSQL: ### RegattaDB RegattaDB reached a sustained insert rate of 196,068 rows per second (2 minutes and 33 seconds for the entire insertion phase). The recommended technique for RegattaDB is to use insert statements that each contain multiple rows. Concurrency can further boost performance. > Note:Unlike many databases, a RegattaDB client can submit multiple transactions concurrently over a single connection/session. Therefore, concurrency can be achieved by either multiple sessions/connections or by a single connection. An interesting aspect of RegattaDB’s architecture is that it does not need to store the row’s data first to a WAL. Instead, the row’s data is written only once, directly to the log-structured row-store. In other databases (and PostgreSQL is not an exception), the row’s data is written twice: first to the WAL, and later to the heap file. Avoiding that “double write” write amplification is a RegattaDB optimization that further improves its performance and performance efficiency. It should be noted that the insert operations obeyed strong ACID, and we did not use any techniques such as bypassing SQL parsing. The insertion rate was optimal, and RegattaDB effectively saturated the underlying disk. ### PostgreSQL For PostgreSQL, we began by using a similar insertion technique to what we used for RegattaDB – that is, multiple rows inserted per statement, and with concurrency. Note that the concurrency was achieved by multiple connections/sessions since PostgreSQL cannot send multiple concurrent transactions per connection/session. #### The INSERT Technique The insertion rate was low: less than 10,000 rows per second. This surprised us. Sure, we did expect some write amplifications (TOAST, WAL, etc.), but that might have resulted in PostgreSQL performing maybe 2X or 3X slower than RegattaDB. However, we observed a much higher factor. We tried to further play with concurrency, with the number of rows per insert statement, etc. However, we didn’t reach any meaningful improvement. At a later stage we further optimized PostgreSQL’s WAL and were able to improve the INSERT technique to around 14,800 rows per second. See Figure 1. #### The COPY Technique Since we were not satisfied with the results of the INSERT approach, we switched to another technique that is recommended by PostgreSQL: The COPY command. With that technique, the client streams rows to the database using a protocol that bypasses SQL parsing. It still obeys ACID rules, so we found that technique “legit”. A single COPY resulted in a too-low rate. We played with concurrency – that is, divided the 30 million rows population among multiple concurrent COPY operations. That improved things, yet increasing the concurrency hit a glass ceiling very quickly. > Note:Dividing each COPY stream to smaller bulks, and executing them serially, concurrently to other COPY streams, did not help improve the PostgreSQL insertion rate. We then tried some additional PostgreSQL tuning parameters like further increasing WAL size. It made a difference. With a single COPY we reached an insertion rate of 11,081 rows per second (slightly more than 45 minutes), and with a concurrency level of 8, we reached a rate of 22,924 rows per second (21 minutes and 49 seconds). Higher concurrency levels did not improve results any further. #### Discussion The maximum insertion rate that we were able to achieve with PostgreSQL was 22,924 rows per second (vs. RegattaDB’s 196,068 rows per second). PostgreSQL’s write amplifications (caused by the slotted pages data layout approach), as well as the fact that RegattaDB does not need to write to any WAL for its row’s data, are probably only part of the picture. The additional explanation is a bit more speculative: We presume that PostgreSQL was, on one hand, not able to saturate the disk with concurrency level of one (very reasonable), but on the other hand, suffering from some sort of internal contentions when higher concurrency level values were used. Note that the client-side was not stressed at all, so that was not the source of the problem. Figure 1 summarizes the insertion phase results. Image: Figure 1: Insertion phase results for PostgreSQL, by insertion method and concurrency level, in both duration (seconds) and rate (rows per second) terms.The presented PostgreSQL concurrency levels are not applicable for RegattaDB, thus the RegattaDB performance is depicted as a constant value independent of the PostgreSQL concurrency. Figure 1: Insertion phase results for PostgreSQL, by insertion method and concurrency level, in both duration (seconds) and rate (rows per second) terms.The presented PostgreSQL concurrency levels are not applicable for RegattaDB, thus the RegattaDB performance is depicted as a constant value independent of the PostgreSQL concurrency. ### Conclusion We tried to optimize PostgreSQL as much as we could. RegattaDB was able to insert the 30 million rows8.6X faster than PostgreSQL. The reasons for that difference are a variety of data layout and storage-engine I/O-amplifications, as well as possible contentions and other overheads in PostgreSQL. RegattaDB’s data layout showed good performance (and performance efficiency) that was close to the physical limits. ## The Post-Insertion Full Scan Phase We inserted the rows, and reached the first full scan phase. As mentioned, we wanted the full scan to access multiple parts of each of the rows, and yet be lightweight in terms of CPU and network. We used the following statement: ```text SELECT count(*) FROM test_table WHERE left(c1,4)='abcd' OR left(c2,4)='abcd' OR left(c3,4)='abcd' OR left(c4,4)='abcd' OR left(c5,4)='abcd' OR left(c6,4)='abcd' OR left(c7,4)='abcd' OR left(c8,4)='abcd' OR left(c9,4)='abcd' OR left(c10,4)='abcd'; ``` We planted the data in such a way that none of the rows would satisfy the predicate, so that the entire predicate must be calculated, accessing 10 different cells of each row. ### RegattaDB RegattaDB performed the full scan in 50 seconds (599,520 rows per second). The underlying disk was fully saturated. It should be noted that RegattaDB’s row-store data layout following the insertion phase was completely “fresh”, giving optimal results. That was our expectation. We also expected the full scan duration to be somewhat increased following the next lengthy update phase, but in a reasonably limited and “controlled” manner. We repeated the full scan. The results were the same. Good. Let’s switch to PostgreSQL now… ### PostgreSQL #### First Full Scan is Slower Switching to PostgreSQL, we noticed that the first full scan (just after the insert phase) was significantly slower than the next, repeated, full scans. We will provide more information about this later. For now, let’s review results that exclude those slower “first” full scans. #### The Results Ignoring the very-first (slower) PostgreSQL full scan, the next full scan took 277 seconds.5.5X slower than RegattaDB(50 seconds). PostgreSQL was configured to run with 8 parallel workers, as recommended by PGTune. The heap and the TOAST files were in a reasonably “fresh” state, meaning that we expected PostgreSQL to give its best. At a later phase of the experiment, we discovered that increasing the number of parallel workers to a larger number improved PostgreSQL’s full scan performance. We then re-ran the full scan with larger number of parallel workers, and we were able to improve the results: With 20 parallel workers, the scan took 151 seconds, and PostgreSQL maxed out with a value of 60 parallel workers, resulting in 136 seconds, only2.7X slower than RegattaDB. ### Intermediate Conclusion Both databases saturated the disk, reaching around 6 GB/s of read throughput. And yet, RegattaDB was 2.7X faster. Why is that? The answer is simple: PostgreSQL’s data layout approach causes read amplifications that hurt the overall performance and performance efficiency. However, that’s how those data layouts behave in their “fresh” state. How will they “age”? We will soon find out. Image: Figure 2: Post-insertion full scan results for PostgreSQL, by concurrency level, in both duration (seconds) and rate (rows per second) terms. The presented PostgreSQL concurrency levels are not applicable for RegattaDB, thus the RegattaDB performance is depicted as a constant value independent of the PostgreSQL concurrency. Figure 2: Post-insertion full scan results for PostgreSQL, by concurrency level, in both duration (seconds) and rate (rows per second) terms. The presented PostgreSQL concurrency levels are not applicable for RegattaDB, thus the RegattaDB performance is depicted as a constant value independent of the PostgreSQL concurrency. ### PostgreSQL First Full Scan is Slower Before we move on, let’s talk about PostgreSQL’s first full scan after the insertion phase. As mentioned above, we noticed that the very first full scan, following the insertion phase, took longer. How long? For example, with the fastest 60 parallel-workers setting, the first full scan took 245 seconds while the second (and the following) took 136 seconds. The first PostgreSQL scan was 1.8X slower than the following PostgreSQL scans. One may suggest it’s the effect of read-caching. However, it is arguably not the explanation for what we observed. In fact, we measuredmeaningful writing activityduring the first full scan, and zero writing activity for the later scans. Apparently, as part of the full scan, for the heap pages it read, PostgreSQL opportunistically set the “committed” bit in the row headers, which caused those pages to be then flushed to disk. That activity is related to the MVCC processing of those recently written row-versions (regardless of whether those were inserts or updates). That meaningful write activity slowed down the scan, and the scan read I/Os were effectively blocked by those write I/Os. > Note:Those pages were already written to the heap file earlier, and became dirty due to the MVCC-related metadata changes described above. So, the data was written once to the WAL, then written (second time) to the heap files, and then rewritten (“third time”) to the heap files. We may dive into a more detailed explanation in a future blog, where we will compare RegattaDB’s and PostgreSQL’s MVCC approaches. ## The Update Phase To see how the data layouts “age” (=perform over time), we started a lengthy phase of “point-update” transactions, where each transaction updates one random cell of one random row. The row was identified in a unique manner (e.g., using a primary index in PostgreSQL). How lengthy did we want to get? Well, we wanted to go beyond one billion updates. We mainly viewed that entire process as a “utilitarian” phase, and yet we tried to get a healthy point-update transaction rate. We increased the concurrency level of transaction submissions to get higher transaction rates. ### PostgreSQL With PostgreSQL: - Concurrency level 48:We were able to achieve an update rate of 22,126 transactions per second (TPS) with a concurrency level of 48. Higher concurrency levels did not improve the rate. However, after ~684 million point-update transactions (~8 hours and a half), we reached the end of disk capacity and were forced to stop the experiment. We had a dedicated ~1.5 TB disk, and only 30 million 10KB rows (around 300 GB net capacity). Just for the elimination of doubt: The updates do not increase the number of rows or change individual row sizes. - Concurrency level 24:Re-doing the experiment with a concurrency level of 24 (which lowered the update rate to 15,035 TPS) allowed PostgreSQL to complete without overflowing the disk capacity. What happened here? This has to do with PostgreSQL’s MVCC design. More specifically, with PostgreSQL’s unneeded row-version cleaning mechanism:VACUUM. Before we continue with our analysis, let’s briefly discuss the topic of unneeded row-version cleaning. #### About Row-Version Cleaning and VACUUM In PostgreSQL, any new row-version of a row is written elsewhere on disk, and the previous row-versions of the row are not overwritten or removed. Those older row-versions may becomeunneededvery quickly. Terminology:We use the termUnneeded Row-Versionto denote a row-version that no transaction could possibly read. At any given moment in time, a row may have multiple row-versions that could be read by various transactions that use a variety of point-in-times for their readings. However, once those transactions complete, some of the row-versions may effectively become unneeded. However, PostgreSQL cannot know where those unneeded row-versions are located on the disk. In addition, calculating whether such an older row-version is indeed unneeded is non-trivial and is subject to a variety of restrictions. PostgreSQL’s VACUUM is a process that crawls the tables’ heap files, scanning all the row-versions, and checking, for each row-version, whether VACUUM can deduce that it became unneeded – all that, subject to a variety of restrictions that may cause VACUUM not to classify the row-version as unneeded although it actually is… For example, row-versions that are younger than the oldest existing snapshots cannot be categorized as unneeded even if they are. The VACUUM algorithm is not amazingly efficient as it needs to crawl and check every row-version (not to mention misdetections due to the various restrictions that may delay the detection for later crawls…). There is an additional complication when the rows are indexed, as the way VACUUM works requires it to perform a heap scan, then an index scan (for each of the table’s indexes), and then a second heap scan, which further increases its work as well as further delays its row-version cleaning. VACUUM may badly, and often unpredictably, affect the overall I/O performance of PostgreSQL. However, disabling VACUUM in an effort to gain performance would lead to capacity explosion. In our case, disabling VACUUM during the update phase would inflate the size of the heap files to potentially gigantic size – orders of magnitudes larger than our disk’s capacity. #### Row-Version Cleaning in RegattaDB RegattaDB treats unneeded row-version cleaning completely differently. RegattaDB’sRangertechnology maintains precise metadata about which row-versions became unneeded. There is no crawling, no approximation, and no dependency on the oldest active snapshot. Long-running analytical queries do not stall transactional cleanup. OLTP and OLAP workloads run concurrently over the same data without inflating each other's version debt. Comparing VACUUM with RegattaDB’s Ranger is a topic for another blog. Stay tuned… But for now, let’s get back to our utilitarian update phase… #### Analysis of the Capacity Overflow (Concurrency Level 48) PostgreSQL’s point-update transactions and VACUUM “competed” with each other, as both needed to perform disk I/O and CPU work. When updates are “winning” then more and more old unneeded row-versions remain, and the newer updates increase the heap file size. On the other hand, if more priority is given to VACUUM, then it needlessly consumes (or shall I say, wastes) more and more disk I/O resources for its crawling, which further slows the update transaction rate. The competition between the point-update transactions and VACUUM has chaotic attributes. It’s somewhat fluctuating. In the concurrency level 48 case, the updates eventually won. VACUUM lost. As a result, the disk overflowed… Philosophically, each point-update leaves a previous row-version cleaning “debt”. Many systems have to (or are intentionally designed to) defer some debt work to asynchronous background tasks. Such systems should arguably be able to deal with increased background debt, for example, by pushing back the foreground activities. This is almost always non-trivial. At Regatta, we nicknamed that phenomenon “the curse of the background”. It seems that PostgreSQL’s internal throttling mechanisms could be improved (which probably is non-trivial due to the nature of the VACUUM algorithm), or that users would need to dynamically throttle their workloads. > Note:Agentic AI workloads are less predictable than human-scale workloads. Requesting agents to “calm down” will probably not always be a good strategy. The problem of unneeded row-version cleaning would become even more challenging in combined transactional (OLTP) and analytical (OLAP) workloads, as the mixture of lengthier and shorter transactions and snapshots might make the inability to clean row-versions that are younger than the oldest active snapshot more painful. RegattaDB’s unneeded row-version cleaning is also done in the background. As mentioned, it’s much more efficient (no crawling, knowing exactly which row-versions to remove, and “just on time” removal). Additionally, in extreme cases, those background operations can dynamically throttle foreground activities. Therefore, for example, a massive update transactional workload will not cause RegattaDB’s capacity to grow indefinitely… #### Continuing with Concurrency Level 24 As mentioned earlier, we restarted the entire experiment with concurrency level 24 for the update phase. The (rather fluctuating) average point-update transaction rate was 15,035 TPS. At that concurrency level, the point-update transactions and VACUUM were obviously still “competing” with each other. When the updates were “winning” then older unneeded row-versions remained, and the newer updates increased the heap file size – which is practically irreversible. We executed 1.2 billion point-update transactions. That process took approximately 22 hours. Once we stopped the updates, we let VACUUM and any other background processes complete before we moved on. At the end, the heap file size was 360 GB (increased sixfold from 57 GB before the updates started). The TOAST file size grew from 278 GB (before the update phase) to 761 GB, even though the number of rows in the table remained unchanged. That sparseness is clearly undesired for both capacity consumption and performance reasons although, as discussed below, it became just one contributor (and not the major one) to the performance results of the full scan that was executed after the update phase. > Note:In another run under the same conditions, the heap size grew to ~450 GB instead of the 360 GB reported above – a reminder of how unpredictable the competition between the point-update transactions and VACUUM can be. (The other results in this post were consistent across multiple runs; this variability was specific to heap growth.) ### RegattaDB We let RegattaDB perform the same number of point-update transactions (1.2 billion), at a rate of ~29,500 TPS (we did not try to optimize that, quite frankly) and completed the phase in ~11.5 hours. > Note:We executed this update phase with various levels of concurrency, including concurrency levels of 32, 64, 128, 256 and 512. In all those cases, the results (capacity-consumption-wise, as well as the following full scans) were effectively the same. That demonstrated how RegattaDB’s internal mechanisms balance background and foreground activities without suffering from the “curse of the background” phenomenon. In the end, RegattaDB’s data layout was about 90% dense, which would be friendlier to the later full scan performance. > Geek note:RegattaDB’s log-structured row-store data layout is not residing inside a file, as RegattaDB bypasses the filesystem and works directly on top of raw block storage. The data layout inherently and automatically maintains its density. In our case, the data layout did not really become sparse. However, even in cases where RegattaDB’s row-store data layout becomes sparser, RegattaDB does not need to read the “empty spaces”, as its algorithms “know” where those empty spaces reside. Furthermore, as an MVCC data layout, there may be stored row-versions that our full scan won’t need (e.g., for other timestamps, serving reads for other point-in-times). RegattaDB’s full scan algorithms will not need to read such row-versions at all! It can simply skip them. PostgreSQL, on the other hand, cannot avoid reading empty spaces, just to realize they are empty, and must read all the stored row-versions, regardless of whether they are related to that full scan or to other points-in-time. In our experiment, we did not focus on exemplifying those differences. We may post about this topic in another blog post soon. ## The Post-Update Full Scan Phase We completed the 1.2 billion point-updates, waited for background processes to complete, and initiated the same full scan as performed before the update phase. As a reminder, we wanted to see how the data layouts “aged” after handling those update transactions. ### RegattaDB For RegattaDB, we expected the full scan duration to increase in a reasonably limited and controlled manner following the lengthy update phase. Indeed, RegattaDB performed the full scan in 59 seconds (508,810 rows per second). The expected small degradation versus the first “fresh” scan was mainly accounted for by the difference in read I/O sizes that were submitted to the underlying disk. Repeating the full scan provided similar results. The results were in-line with what we expected. As already mentioned earlier, we expected the post-update full scan duration to be somewhat increased, but in a reasonably limited and “controlled” manner. ### PostgreSQL #### First Attempt Switching to PostgreSQL. As usual, let’s completely exclude the “first full scan that is slower”. With the recommended 8 parallel workers, PostgreSQL’s (second) full scan took 5,506 seconds, i.e. slightly less than 1 hour and 32 minutes(!). This is 93X slower than RegattaDB. The underlying disk was very far from being saturated. #### Improving PostgreSQL We realized that PostgreSQL is most probably unable to submit sufficient concurrent read I/Os to the disk – possibly because some of the reads depend on others (e.g. we have heap and TOAST elements in town, including the heap page that references a TOAST-ed cell that requires an additional TOAST index lookup to fetch , and so forth). As a result, we started to gradually increase the number of parallel workers (including re-runs of the full scan). As we increased it, the full scans’ durations became shorter, and the utilized disk bandwidth became higher, until we reached the limit of disk saturation. Voilà. At that point, as expected, further increase in the number of parallel workers did not help anymore. That point was at 60 parallel workers. > Note:We can’t say whether using such a large number of parallel workers would have negative side-effects for PostgreSQL’s normal operation. With 60 parallel workers, PostgreSQL executed the full scan in1,470 seconds, i.e.24 minutes and 30 seconds.25X slower than RegattaDB. > Note:This result excludes the “first scan” (which was even slower). Image: Figure 3: Post-update full scan results for PostgreSQL, by concurrency level, in both duration (seconds) and rate (rows per second) terms. The presented PostgreSQL concurrency levels are not applicable for RegattaDB, thus the RegattaDB performance is depicted as a constant value independent of the PostgreSQL concurrency. Figure 3: Post-update full scan results for PostgreSQL, by concurrency level, in both duration (seconds) and rate (rows per second) terms. The presented PostgreSQL concurrency levels are not applicable for RegattaDB, thus the RegattaDB performance is depicted as a constant value independent of the PostgreSQL concurrency. ## Analysis of the Full Scans’ Performance ### Result Summary Let’s try to analyze the following full scan related results: - Prior to the update phase,PostgreSQL’s full scan executed 2.7X slower than RegattaDB (136 seconds vs. 50 seconds). Both were able to saturate the disk (with a healthy ~6 GB/sec read throughput). - After the update phase,PostgreSQL’s full scan executed 25X slower than RegattaDB (1470 seconds vs. 59 seconds) - PostgreSQL’s full scan performance deterioratedfrom around 136 seconds prior to the update phase to 1,470 seconds following that phase –a deterioration of 10.8X. > Note:We completely ignored PostgreSQL’s extra slowness “in the first full scan”. We only worked with results of the scans “after the first scan”. ### Slotted Page Row-Overflow Solution has its Cost #### PostgreSQL Prior to the update phase, PostgreSQL’s full scan was 2.7X slower than RegattaDB, mainly because a slotted pages data layout requires some on-disk solution for the rows that cannot fit a slotted page (TOAST). Such a solution unavoidably involves some levels of read amplification. PostgreSQL had to read each row from the heap as well as from the TOAST area. Prior to the update phase, since each of the rows was inserted as a whole, the TOAST columns of each row tended to sit together in the same disk page. As a result, the read amplification (vs. RegattaDB) was real, and yet reasonably bound. #### RegattaDB RegattaDB’s row-store data layout was dense and therefore no read amplification occurred. ### Heap File Sparseness (After the Update Phase) #### PostgreSQL As mentioned, after the update phase PostgreSQL’s heap file became sparser –6.3Xlarger than its size just after the insertion phase. That would increase theheap file part of the scanby about6.3X. In general, this could become a meaningful deficiency for PostgreSQL full scans, related to the entire VACUUM and MVCC operation. Interestingly, however, in our specific case, it was arguably not the main contributor to the degradation (the “TOAST locality effect” described below is the dominant contributor). #### RegattaDB In contrast, RegattaDB’s row-store data layout generally maintained its density. > Note:As already discussed earlier, RegattaDB’s full scan can “skip empty areas” (as well as not need to read row-versions that are not related to the relevant point-in-time of the concrete full scan). Therefore, and especially with larger rows, even a sparser data layout wouldn’t necessarily meaningfully degrade RegattaDB’s full scan performance. ### The TOAST “Locality Effect” The update phase gradually deteriorated the locality of the TOAST-ed data. As the update phase progressed, cells started to move around to other areas in the TOAST file. As a result, at the end of the update period, reading of each row required quite a few additional read I/Os from disk. When PostgreSQL reads a cell of 0.5KB from disk, it still needs to read the entire 8KB page. The worse the locality is, the higher the read amplification becomes. That was the dominant part of PostgreSQL’s performance degradation. ### Analysis Summary To conclude: 1. Prior to the update phase, PostgreSQL’s full scan executed 2.7X slower than RegattaDB because the slotted pages data layout requires some on-disk solution for the rows that cannot fit a slotted page (TOAST). That solution unavoidably introduced some levels of read amplification. 1. After the update phase, PostgreSQL’s full scan executed 25X slower than RegattaDB because of the combination of: - The need for a solution for overflowed rows (see (1) above). - The sparseness of the heap file (6.3X larger than after the insertion phase). - The loss of locality among cells in the TOAST file. ## Deterioration Over Time The above analysis demonstrates why data layout performance should be measured over time. The performance of a “fresh” data layout may deteriorate over time, and different data layouts may vary in their deterioration characteristics. The experiment described so far had two “measurement points” for the full scans: One before the update phase and the other after the 1.2 billion point-updates. As additional evidence for the above analysis, let’s view the deterioration over time, by using additional intermediate measurement points. We re-ran the experiment, and measured full scans after 150 million, 300 million, 600 million, and 900 million point-updates, both PostgreSQL and RegattaDB. The figure below shows the results, combined with the post-ingress results (i.e., the 0 point-updates value) and the full scan results after 1.2 billion updates. Image: Figure 4: The post-update full scan deterioration, by number of point-updates. The scans were performed on a quiet database. The value of 0 refers to the full scan performance prior to the update phase. Figure 4: The post-update full scan deterioration, by number of point-updates. The scans were performed on a quiet database. The value of 0 refers to the full scan performance prior to the update phase. PostgreSQL’s deterioration begins very early. After 150M point-updates, it is already 4.5X slower than prior to the beginning of the update phase. RegattaDB’s degradation is very mild and is arguably not correlated with the number of point-updates. To strengthen the observation that RegattaDB’s scans are not affected by the “aging” of the data layout, we re-tested RegattaDB with larger number of point-update transactions, reaching up to2.4 billionupdate transactions, as shown in Figure 5. Image: Figure 5: RegattaDB’s post-update full scan duration, as a function of the number of point-update transactions preceding it, extending up to 2.4 billion update transactions. Figure 5: RegattaDB’s post-update full scan duration, as a function of the number of point-update transactions preceding it, extending up to 2.4 billion update transactions. ## Conclusion ### Summary In this experiment we demonstrated some of the differences between RegattaDB’s row-store data layout and PostgreSQL’s slotted pages. We focused on rows that are larger than a slotted page, and saw how, for those rows, the performance and performance efficiency differences between RegattaDB and PostgreSQL became very meaningful. While the lion share of the performance differences was related to the difference between PostgreSQL’s TOAST/slotted-pages vs RegattaDB’s log-structured approaches, we also observed significant differences in MVCC handling (e.g., VACUUM, update-MVCC data on read) as well as performance degradation resulting from data layout sparseness. We also saw how RegattaDB’s WAL-free data hardening could further improve performance and performance efficiency. In addition, we observed how differently RegattaDB and PostgreSQL deal with “the curse of the background”, and with high level of update transaction concurrency. The experiment was done with fairness in mind (e.g., optimizing PostgreSQL, letting each database do its thing in its best recommended manner) and with full ACID. ### Summary of the Results #### Highlights - RegattaDB was8.6Xfaster than PostgreSQLinserting the rows to the table. - RegattaDB was2.7Xfaster than PostgreSQL in full-scanning a “fresh” data layout (just after the insertion phase) - RegattaDB was25Xfaster than PostgreSQLin full-scanning an “aged” data layout (following 1.2 billion point-update transactions) Below is a summary of the main results in the various phases of the experiment: #### Insertion Phase - RegattaDB’s ingress was8.6Xfaster than PostgreSQL. It inserted 30 million rows in2 minutes and 33 seconds(196,068rows per second) while it took PostgreSQL21 minutes and 49 seconds(22,924rows per second) to do the same. - In addition to its data layout that made storing medium-sized rows more efficient, RegattaDB did not need to write the row data to a WAL, which further contributed to its performance and performance efficiency. #### Post-Insertion Full Scan Phase - After the insertion completed, and before the update transactions began, RegattaDB performed the full scan in50 seconds(599,520rows per second) and PostgreSQL performed the same scan in136 seconds(220,022 rows per second) – RegattaDB was2.7Xfaster. - The data layouts were in their “fresh” state, before they started to “age” by ongoing update transactions. At their fresh state, the data layouts were completely dense, and PostgreSQL’s TOAST locality was in a good shape. All that resulted in the best full scan results for both databases. - Both databases’ full scans saturated the disk. And yet, RegattaDB was meaningfully faster, as PostgreSQL’s data layout involved a meaningful read amplification that was the source of the performance differences. - PostgreSQL’s “first scan” following write activity wasmeaningfully slower(245 secondsvs. 136 seconds in repeated scans) due to MVCC handling that is done synchronously to related read operations. Regatta’s “first scan” is as fast as the next scans. #### Update Phase - PostgreSQL was not able to cope with a sustained point-update transaction concurrency level of 48 (that was maxed at 22,126 TPS) and, as a result, the in-use disk capacity (~1.5 TB) overflowed. - VACUUM and the update transactions competed in a somewhat chaotic manner. It seems that PostgreSQL’s internal mechanisms were not able to cope with the “curse of the background”. - PostgreSQL completed the update phase (1.2 billion point-update transactions) with a concurrency level of 24 (15,035 TPS) without overflowing the disk, but with anon-insignificant sparseness. - Without special optimizations, handled as a “utilitarian phase”, RegattaDB completed the update phase at a rate of ~29,500 TPS. - PostgreSQL completed the update phase in ~22 hours and RegattaDB completed that phase in ~11.5 hours. - RegattaDB was able to perform those 1.2 billion point-update transactions with avarying levels of concurrency, such as64, 128, 256, 512, without being hit by the “curse of the background”. This is a result of: - RegattaDB’s Rangertechnology - an efficient cleaning of unneeded row-versions - Internal throttling mechanismsthat dynamically balance foreground activities with background activities effectively - At the end of the update phase, RegattaDB’s row-storedata layout remained dense. #### The Post-Update Full Scan Phase - After the update phase, as well as after associated background tasks completed (e.g., VACUUM), RegattaDB performed the full scan in59 seconds(508,810rows per second) and PostgreSQL performed the same scan in24 minutes and 30 seconds(only20,415 rows per second). RegattaDB was25Xfaster. > Note:PostgreSQL’s even slower “first scan” was excluded from the reported results. - Those results demonstrate howimportant it is to measure data layout performance over time, letting it “age”, and inspect the deterioration over time. - PostgreSQL’s data layoutmeaningfully deteriorated over time, mainly due to the slotted pages’ row-overflow handling (TOAST) mechanism, and its loss of locality over time. In addition, the sparseness of the slotted pages data layout contributed to the performance degradation. - RegattaDB scan performance was similar before and after the update phase (with an expected, mild yet “controlled” degradation). That degradation was not correlated with the number of update transactions anddoesn’t change over time. - Re-runs of the experiment for RegattaDB with an expanded update phase (up to 2.4 billion point-update transactions) reinforced the conclusion that RegattaDB scans performance was not correlated with the number of previous update transactions. ### Additional Topics The experiment demonstrates scenarios and dynamics that are relevant for real-life workloads. Traditional relational databases use slotted pages and users were traditionally educated to prefer small rows for performance reasons. However, modern data does and will require more data per row. As for the minimized cache: That approach was taken in order to focus on measuring data layout performance in as ‘’clean” manner as possible. However, it should be noted that this configuration is equivalent to other real-life scenarios where one has a large amount of data that is much larger than the RAM of the database server. Deficiencies in data layout performance cause users to limit their on disk capacity such that it would not be meaningfully larger than the database server’s RAM. That obviously hurts overall TCO, as more and more servers will be required for larger data. In our experiment we used a table with only 30 million rows. Modern workloads, such as agentic AI, as well as other types of modern data may require significantly larger number of bigger rows, resulting in much larger capacity. Therefore, our experiment arguably represents real life configurations. --- # Imagining OpenAI’s 800-million-users PostgreSQL at scale without replicas or offloading, on RegattaDB Source: https://regatta.dev/blog/openai-postgres-regattadb Updated: 2026-10-15 Author: Boaz Palgi Categories: Technology In January, OpenAI engineer Bohan Zhang published"Scaling PostgreSQL to power 800 million ChatGPT users" (https://openai.com/index/scaling-postgresql/). It is excellent engineering. A single primary PostgreSQL instance on Azure, with nearly 50 read replicas, serves"millions of queries per second for 800 million users."It is also an unusually candid account of where that architecture runs out of room, and it closes by saying the team will keep exploring"sharded PostgreSQL or alternative distributed systems, as our infrastructure demands continue to grow." This post takes five constraints the article describes, in OpenAI's own words, and shows how a distributed SQL database, RegattaDB, approaches each one. RegattaDB was built from scratch to run transactions, analytics and vector search in a single engine, from one node to clusters of thousands of nodes. ## 1. Reads are scaled by copying the database OpenAI's workload is read-heavy:"Since our workloads are primarily read-heavy, and we've implemented extensive optimizations, the current architecture still provides ample headroom to support continued traffic growth."The way to serve that many reads from PostgreSQL is to copy data over the network to replicas on other nodes. Each replica holds a full copy of the entire database and replays every write the primary makes, so with nearly 50 replicas the same data is stored, and the same writes are applied, about 50 times over. That results in a system-wide 50x write amplification for each write. Each replica is another instance to provision, pay for and keep in step with the primary, and a replica of this kind trails the primary it copies. With RegattaDB,reads, as well as writes, scale linearly by adding nodes to the same cluster. Every node serves queries on current live data, so there is no replica fleet to build, no write amplification, and no copy to fall behind. ## 2. Only one machine can write The OpenAI article is direct about the limit:"With only one writer, a single-primary setup can't scale writes. Heavy write spikes can quickly overload the primary and impact services like ChatGPT and our API."OpenAI's solution is to keep the primary as free as possible:"We minimize load on the primary as much as possible—both reads and writes—to ensure it has sufficient capacity to handle write spikes."On writes, it says:"For write traffic, we've migrated shardable, write-heavy workloads to sharded systems such as Azure CosmosDB. Workloads that are harder to shard but still generate high write volume take longer to migrate, and that process is still ongoing."Ironically, the need to replicate each write to many destinations makes the load on the primary even higher. Not only does one node need to serve all the writes, but it also needs to work meaningfully harder on each such write in order to replicate it to the destinations. Even this solution creates many additional challenges. Reads have to be pushed out to replicas, yet some must still stay on the primary. Write-heavy workloads have to be moved to a second database, and the ones that are hard to shard are still being migrated. With RegattaDB,transactions execute across many nodes, with serializable ACID guarantees across the whole cluster. Writes are spread across the entire cluster and are not forced to be executed by a single node. Therefore, adding nodes adds write capacity, and a spike is absorbed by the cluster instead of landing on one machine. Write-heavy workloads can also stay in the same database, instead of moving to a separate system such as Cosmos DB. ## 3. Replicas cannot be added indefinitely Every replica adds work for the primary:"As the number of replicas increases, the primary must ship WAL to more instances, increasing pressure on both network bandwidth and CPU."Every write has to reach, and be replayed by, every replica. And:"we can't keep adding replicas indefinitely without eventually overloading the primary."OpenAI's answer is cascading replication, where intermediate replicas"relay WAL to downstream replicas,"an approach that"allows us to scale to potentially over a hundred replicas without overwhelming the primary."It is a clever fix, but it also adds a replication topology to operate and debug. With RegattaDB,there is no single primary shipping its log to a growing fan-out of copies. Write capacity grows with the nodes in one cluster, so this ceiling, and the cascade built to push it back, do not arise. ## 4. Sharding is the usual escape, and it is expensive Why not shard PostgreSQL?"The primary rationale is that sharding existing application workloads would be highly complex and time-consuming, requiring changes to hundreds of application endpoints and potentially taking months or even years." Application rewrite is not the only cost. Sharding a single-node database has trade-offs of its own, and it often breaks what developers expect from ACID. Our whitepaper,Dirty Secrets of Sharding (https://regatta.dev/resources/whitepapers/dirty-secrets-of-sharding-whitepaper), covers them. With RegattaDB,the application sees one logical SQL database. The system spreads data and work across nodes, so there are no shard keys to design and no application endpoints to rewrite for the database to scale. ## 5. MVCC makes heavy writes expensive Even where writes are possible, each one is costly inside PostgreSQL. The article explains why:"Although PostgreSQL scales well for our read-heavy workloads, we still encounter challenges during periods of high write traffic. This is largely due to PostgreSQL's multiversion concurrency control (MVCC) implementation, which makes it less efficient for write-heavy workloads. For example, when a query updates a tuple or even a single field, the entire row is copied to create a new version. Under heavy write loads, this results in significant write amplification. It also increases read amplification, since queries must scan through multiple tuple versions (dead tuples) to retrieve the latest one. MVCC introduces additional challenges such as table and index bloat, increased index maintenance overhead, and complex autovacuum tuning." With RegattaDB,RegattaDB's MVCC implementation is very different from PostgreSQL's as well as from other relational databases. Whenever a row has multiple row-versions (i.e., tuple versions) a query can immediately read the right tuple version, without needing to scan through all the row's row-versions. Furthermore, RegattaDB'sRangertechnology allows cleaning of the row-versions that becameunneeded(i.e., dead tuples) in an extremely efficient manner, without needing awkward and wasteful mechanisms such as PostgreSQL's VACUUM that effectively needs to crawl the entire database, seeking for those unneeded row-versions. If you run PostgreSQL at a scale where replicas have become their own project, we would like to hear from you at regatta.dev. Source:Bohan Zhang, "Scaling PostgreSQL to power 800 million ChatGPT users," OpenAI, 22 January 2026,https://openai.com/index/scaling-postgresql/ (https://openai.com/index/scaling-postgresql/). All quotations are from that article. --- # Just added: Watch RegattaDB vs. PostgreSQL: 8.6x Faster Inserts, 25x Faster Scans Source: https://regatta.dev/blog/just-added-watch-regattadb-vs-postgresql-8-6x-faster-inserts-25x-faster-scans Updated: 2026-09-28 Author: Didi Atzmony Our CTO, Erez Webman, recently published "When Rows Outgrow the Page: RegattaDB vs. PostgreSQL TOAST (https://regatta.dev/blog/pvr-toast)," and it has drawn a lot of attention. The post deals with a hot topic: how databases hold up when agentic AI produces rows that are both large and constantly updated. We've now added two short videos that show the results side by side, so you can watch the performance difference for yourself.The test used 30 million rows of about 10KB each, identical bare-metal servers, a tuned PostgreSQL 18.3 and full ACID on both sides. So what do the videos show?They capture two key phases of the benchmark: 8.6x faster inserts.RegattaDB inserted all 30M rows in 2.5 minutes, compared with almost 22 minutes for PostgreSQL. Watch side by side: 8.6x faster inserts Embed: https://player.vimeo.com/video/1226567287 https://player.vimeo.com/video/1226567287 25x faster scans after 1.2 billion updates.On a fresh table, RegattaDB scanned in 50 seconds and PostgreSQL in 136 seconds. Then came the updates.PostgreSQL's scan time ballooned from 136 seconds to 24.5 minutes, nearly 11x slower than its own starting point.RegattaDB still finished in just 59 seconds and held steady through 2.4 billion updates. Watch side by side: 25x faster scans after 1.2 billion updates Embed: https://player.vimeo.com/video/1225581686 https://player.vimeo.com/video/1225581686 It's deeply technical and doesn't pull punches. Written by engineers, for engineers.Read the full post:When Rows Outgrow the Page: RegattaDB vs. PostgreSQL TOAST (https://regatta.dev/blog/pvr-toast) --- # Under the Hood of RegattaDB's Vector Index Source: https://regatta.dev/blog/under-the-hood-of-regatta-s-vector-index Updated: 2026-08-18 Author: Nitai Kluger Retrieval-augmented generation (RAG), recommendation engines, image matchers, and semantic search all use a vector database to identify similarity in a high-dimensional space. To do this efficiently, they must build an index that organizes vectors so approximate nearest-neighbor (ANN) queries can be answered quickly without a full scan of all the vectors in the database. The index is constructed over the data first, then queries are executed against it. These two operations, build and search, are what every vector engine must support. As datasets grow into the millions and billions of vectors, a single-node index (not distributed) is no longer sufficient. Distributed vector indexes become necessary, and with them come real challenges. How is load balanced across nodes? How are resources managed during index construction? How is query execution optimized at the cluster level? RegattaDB is a distributed SQL database that supports both OLTP and OLAP queries, and extends this with native vector capabilities that optimize both index construction and query execution. Admins and operators have full control over resource usage, scheduling, and placement through standard SQL. The sections below cover how RegattaDB handles build and search for vectors, how it compares to pgvector, Qdrant, and Pinecone, and what the end-to-end workflow looks like in practice. ## Building and Searching Every vector index involves two kinds of work:buildingthe index structure over the data, andsearchingit at query time. The two most widely adopted approximate nearest-neighbor (ANN) index methods are HNSW (a graph-based structure optimized for recall and speed) and IVFFLAT (a partition-based structure optimized for memory efficiency). RegattaDB supports both, and optimizes each side of the lifecycle; exposing fine-grained control over how much CPU to dedicate, which cluster nodes participate, and how queries are routed, all through familiar SQL statements. Every vector index involves two kinds of work, build and search. Build is CPU-intensive, and an uncontrolled build on a production cluster that performs additional activities can starve the other transactional, analytical, and search activities, causing performance issues such as latency spikes across the rest of the application. Search is usually done in high throughput, and hence must be fast and parallelized across nodes without overwhelming the cluster. ## Building: Controlled, Localized, and Parallel Index construction in RegattaDB is designed to be predictable and governable. Controlled.In a production cluster, nodes are constantly serving vector searches, transactions and analytical queries. Vector index build can starve those workloads of CPU and memory, introducing performance issues, such as increased latency or even causing timeouts for the rest of the application. RegattaDB makes index construction an explicitly governed operation. The `parallelism` parameter (`FULL`, `HIGH`, `MEDIUM`, `LOW`) controls how many cores each node dedicates to the build, and can be set globally or overridden per node. You also choosewhichnodes build andwhen -so you can build on one set of nodes while another set continues serving production traffic at full speed. Distributed with minimal cross-node overhead.When you create a vector index on a column, the table's data is already natively distributed across the cluster's nodes. Each node builds its own HNSW or IVFFLAT structure over the rows it already stores, independently and concurrently, with almost no inter-node communication. A four-node cluster can build four indexes in parallel, and no vector payloads are shuffled across the network. The following example demonstrates the flexibility of vector index builds in RegattaDB. Here, we use the `ALTER INDEX` statement to execute a rolling build that targets a subset of nodes at a time. The `parallelism` parameter is set to `HIGH`, and is overridden for nodes 4 and 2 to fine-tune resource consumption. There is complete control over both the execution topology and per-node resource usage. ### Step 1: Build the index only on nodes 3 and 4. ```sql CREATE INDEX docs_embedding_hnsw_cosine ON docs USING HNSW (embedding COSINE) WITH ( parallelism = HIGH, modules = ((3), (4, MEDIUM)), ef_construction = 64, m = 16 ); ``` ### Step 2: Check build progress per node. ```sql SHOW VECTOR INDEX MODULES IN INDEX docs_embedding_hnsw_cosine; ``` ### Step 3: Once nodes 3 and 4 reach COMPLETE, extend the index to nodes 1 and 2 with minimal CPU impact. ```sql ALTER INDEX docs_embedding_hnsw_cosine ADD MODULE 1, ADD MODULE 2 LOW; ``` ## Searching: Massively Parallel, SQL-Native, Precision-Routed Vector search in RegattaDB leverages the exact same query planner and optimizer as any traditional SQL query. When a vector search query arrives, any node in the cluster can act as its coordinator. This coordinator fans the request to the relevant nodes, which search their indexes in parallel. After computing their local top-k candidates, these nodes return their findings to the coordinator, which performs a final merge step to determine the global top-k results. From the application side, it is standard SQL: ```sql SELECT doc_id, tenant_id FROM docs ORDER BY embedding <=> '[0.014, -0.092, 0.337, 0.118, 0.044, -0.201, 0.009, 0.411]' LIMIT 10; ``` Query behavior is tunable inline, search strategy, HNSW probe depth, and other parameters are set through the `PARAMS` clause: ```sql SELECT doc_id, tenant_id FROM docs ORDER BY embedding <=> '[0.014, -0.092, 0.337, 0.118, 0.044, -0.201, 0.009, 0.411]' LIMIT 10 PARAMS ( hnsw_ef_search = 128, search_type = APPROX ); ``` Vector search combines naturally with standard SQL filtering, any `WHERE` clause works alongside vector distance ordering: ```sql SELECT doc_id, body FROM docs WHERE tenant_id = 42 ORDER BY embedding <=> '[0.011, -0.101, 0.341, 0.107, 0.031, -0.194, 0.015, 0.405]' LIMIT 5; ``` Because vector search goes through RegattaDB's query optimizer, it benefits from the same dynamic optimizations as any other SQL query - the optimizer chooses execution strategies rather than treating every vector query the same way regardless of data shape. Precision routing.When your data is logically segmented, sometimes there is no need to query the entire cluster, only the nodes that contain relevant data. RegattaDB allows you to target vector searches directly at the nodes containing the relevant data. Limiting the search space to only the necessary nodes reduces the blast radius of individual requests, which translates to higher overall throughput. ```sql SELECT doc_id, body FROM docs ORDER BY embedding <=> '[0.014, -0.092, 0.337, 0.118, 0.044, -0.201, 0.009, 0.411]' LIMIT 10 PARAMS (modules = (0, 1)); ``` The rest of the cluster is completely unaffected by this query. ## How RegattaDB Differs from Other Approaches Pinecone, Qdrant, pgvector, and RegattaDB all support the same vector indexing methods (HNSW, IVFFLAT). The difference is where the control plane lives, where application data is stored, and what the operator is expected to manage. ## pgvector pgvector is a strong fit when you want vector search inside PostgreSQL on a single database instance. It supports exact search by default, approximate HNSW and IVFFLAT indexes, and parallel index build settings through PostgreSQL maintenance workers. But pgvector itself is not a distributed vector engine. Multi-node routing, shard-aware build placement, and cluster-wide top-k reduction are not part of the extension - those concerns are pushed to the surrounding PostgreSQL ecosystem. RegattaDB bakes that distributed execution model into the database layer itself - so multi-node routing, build placement, and cluster-wide top-k reduction work out of the box without assembling external components. ## Qdrant Qdrant is a vector database with a distributed architecture, including sharding, replication, and user-defined shard keys. But it is not a relational database, it does not support SQL, and it has no OLTP or OLAP capabilities. This means vectors in Qdrant live in a separate system from your application’s relational data. While you can duplicate simple attributes into Qdrant's metadata payloads for basic filtering, Qdrant lacks the rich expressiveness of SQL, such as relational JOINs or transactional logic. For complex queries, this architectural split forces your team to manually coordinate two distinct systems at the application layer or maintain complex synchronization pipelines while constantly battling consistency issues. In RegattaDB, vectors sit alongside relational data in the same database, queried with the same SQL, and governed by the same transactional guarantees. There is no separate system to synchronize, no cross-system joins, and no parallel infrastructure to manage. ## Pinecone Pinecone optimizes for a different goal: managed vector infrastructure behind an API. That makes it a good fit for teams that want to get started with vector search quickly without managing any infrastructure themselves. However, there is no direct control over how or where the index is built, and similarly to Qdrant, you are forced to continuously duplicate your transactional/relational data into Pinecone just to filter search results. There is no shared schema with your transactional/relational data, no SQL support, and no OLTP or OLAP capabilities. RegattaDB is aimed at teams that want vector search inside the database, governed with SQL, and collocated with the rest of the application's data model. ### Putting It All Together The end-to-end workflow lives entirely in SQL, no separate SDK, no external service, no context switch between "database work" and "vector work": #### 1. Create a table with a vector column ```sql CREATE TABLE docs ( doc_id BIGINT PRIMARY KEY, tenant_id INTEGER, body VARCHAR(2048), embedding VECTOR(8) ); ``` #### 2. Insert data ```sql INSERT INTO docs (doc_id, tenant_id, body, embedding) VALUES (101, 42, 'Distributed databases and vector search', '[0.014, -0.092, 0.337, 0.118, 0.044, -0.201, 0.009, 0.411]'); ``` #### 3. Build a vector index with controlled parallelism ```sql CREATE INDEX ON docs USING HNSW (embedding COSINE) WITH (parallelism = HIGH); ``` #### 4. Monitor build state per node ```sql SHOW VECTOR INDEX MODULES IN INDEX docs_embedding_hnsw_cosine; ``` #### 5. Search — approximate by default when an index exists ```sql SELECT doc_id, body FROM docs ORDER BY embedding <=> '[0.011, -0.101, 0.341, 0.107, 0.031, -0.194, 0.015, 0.405]' LIMIT 5; ``` #### 6. Force exact search when you need perfect recall ```sql SELECT doc_id, body FROM docs ORDER BY embedding <=> '[0.011, -0.101, 0.341, 0.107, 0.031, -0.194, 0.015, 0.405]' LIMIT 5 PARAMS (search_type = EXACT); ``` Schema definition, data loading, index creation, monitoring, and querying all use the same SQL connection your application already has. Vector indexing in RegattaDB is not a separate subsystem bolted onto the database, it is part of the database. Builds are controlled and transparent: you decide which nodes build, how many cores they use, and you can inspect progress at any time. Searches are parallelized and optimized by the same query planner that handles every other SQL workload. Everything is governed through SQL, lives alongside your relational data, and behaves predictably at cluster scale. --- # Databricks LTAP Revisited: The Compute Cost of Bridging Two Engines Source: https://regatta.dev/blog/databricks-ltap-union-read-compute-cost Published: 2026-07-22 Updated: 2026-08-13 Author: Boaz Palgi Categories: Technology A few weeks ago wepublished an analysis of Databricks LTAP (https://regatta.dev/blog/databricks-ltap-storage-unification-is-not-enough)and the architectural questions it left open. One question in particular stood out: if a transaction commits in Postgres but has not yet landed in object storage, can an analytical query trust what it reads? Since then Databricks published a detailed engineering post on the architecture, and independent engineers have done their own analysis of how LTAP works. It seems it can can handle the freshness problem, however the mechanism it uses carries a performance cost that was not visible in the announcement, and it has direct implications for anyone building agent systems on top of it. This is a follow-up to our original post:Can Databricks LTAP Actually Run OLTP and OLAP at Once? (https://regatta.dev/blog/databricks-ltap-storage-unification-is-not-enough) ## How LTAP Actually Achieves Freshness: The Union Read To understand the cost of LTAP, you first need to understand the data path. When a transaction commits in Lakebase (Postgres), data travels a multi-hop path before it is visible to the analytical engine. The compute node writes WAL records to a Paxos-style safekeeper quorum for durability. A pageserver materializes pages on demand from those WAL records. Background compaction threads then convert row-format data into Parquet files on object storage. Each hop introduces latency. Data that is committed and durable in Postgres is not immediately present in the columnar store. To bridge that gap, LTAP uses what engineers analyzing the architecture have called a union read. When an analytical query executes, the engine simultaneously reads from materialized Parquet files on object storage, in-memory Apache Arrow buffers holding un-flushed transactional state, and any pending updates and deletions not yet compacted into the columnar store. It merges, sorts, and deduplicates these at query time to produce a consistent result. This solves the freshness problem we raised in the original post. But it means the query engine is performing data transformation work at runtime that a unified system would never need to do. The pipeline between the transactional and analytical worlds did not disappear. It moved into the query path. ## What the Union Read Costs The size of the Apache Arrow buffer a query must merge against grows with write throughput. Under sustained agent workloads, that buffer is not small. Query latency is not a stable characteristic of the system. It scales with write load in a way that Databricks has not yet published data to bound this. The union read also reconciles two fundamentally different data structures at runtime: columnar Parquet files optimized for sequential scan, and row-oriented Arrow buffers optimized for transactional writes. That reconciliation consumes CPU on every analytical query. Background compaction threads compound this, running continuously alongside live workloads rather than truly in the background. Additionally, the translation between formats is not cheap either. Databricks' published Lakehouse//RT benchmark is TPC-H Q6: a single-table scan with no joins and no concurrent write load. It does not reflect the union read cost under production conditions. Until Databricks publishes performance data under concurrent write load, the latency profile of analytical queries in production is as an open question. The two-engine model also forces a resource allocation decision that has no good answer. Transactional compute and analytical compute must be provisioned separately, in advance, for workloads that have not yet run. For agent systems this is not just operationally inconvenient, it is structurally impossible. The division of work between transactional and analytical operations across a fleet of agents is not known ahead of time. It shifts continuously based on what agents are doing, what decisions they are making, and what data they need. Provisioning for that in advance means either over-allocating on both sides or accepting that one workload degrades the other when the balance shifts. Neither is a foundation for predictable agent performance. ## The Third Path Databricks Did Not Take Reynold Xin, Chief Architect at Databricks, framed the history of this problem as a binary choice: HTAP tried to unify transactional and analytical workloads through a single engine and failed. LTAP unifies them through a single storage layer. However, the union read is the cost of that choice. But that framing assumes the engine itself cannot be rethought. It assumes that MVCC, slotted pages, WAL double-writes, and process-per-connection concurrency are fixed constraints to work around rather than architectural decisions that can be unmade. The reason previous attempts at HTAP failed is because every attempt started with an existing construct and tried to extend it to handle analytical workloads. The contention was structural because the engine was never designed to avoid it. Extending a system built for one workload to handle another does not change what it is at the core. RegattaDB starts from a different constraint. Rather than extending an existing engine or bridging two engines at the storage layer, it rebuilds the engine from the ground up with the requirement that all three workloads, transactional, analytical, and vector, run simultaneously without contention. A few specifics on what that means in practice: - Version management.RegattaDB replaces MVCC's VACUUM-based cleanup with the Ranger, a patented technology that tracks exactly which row versions became unneeded at the moment a snapshot is removed. There is no crawling, no approximation, and no sensitivity to the oldest active snapshot. Long-running analytical queries do not inflate transactional version debt because the version management system was designed from the start to handle both workloads concurrently without penalizing either. - Storage layout.RegattaDB uses a log-structured storage layout rather than slotted pages. This eliminates the read amplification that Postgres's page layout produces under mixed workloads, avoids TOAST indirection for variable-size rows, and removes the need for runtime reconciliation between row and columnar formats. Scans read only the data that is actually needed. - Writepath.RegattaDB writes the row data directly to its log-structured layout without a write-ahead log (WAL). This removes the double-write I/O penalty that makes the Postgres write path expensive under concurrent load and eliminates the WAL as a bottleneck in the path between a committed transaction and a queryable result. The result is not a bridge between two engines with a union read at the crossing point. It is one engine, built from the storage layer through theconcurrency model (https://regatta.dev/products/regattadb-concurrency-control-serializable-isolation-without-locks-snapshots-or-clock-sync)and query parser, so that the conditions requiring a bridge never arise. There is no Arrow buffer to merge against because there is no separation between the transactional and analytical execution paths to begin with. ## What This Means for Agent Workloads For agent systems the union read has a specific consequence. An agent decision loop that triggers an analytical query under high write load is not getting a clean columnar scan at predictable latency. It is getting a union read whose cost scales with the size of the un-flushed Arrow buffer, which scales with write throughput. For agents where decision latency matters and write load is sustained, that variability is a structural property of the architecture, not a configuration problem. Vector search compounds this. pgvector runs directly on the Postgres process, competing with the same write path that feeds the Arrow buffer. Under concurrent transactional load, vector index maintenance degrades query latency for both workloads at the same time. All three workloads, transactional, analytical, and vector, are contending on the same compute with no architectural separation between them. RegattaDB runs all three workloads under a single concurrency model with no union read, no cross-engine coordination, and no runtime format reconciliation. The latency profile of an analytical query does not change as write throughput increases because the architecture does not require a merge step between two different representations of the same data. Ultimately, with RegattaDB, you canscale both (guaranteed consistent) transactional and (completely currrent) analytical workloads (https://regatta.dev/products/20b-row-join)and have them run within the same engine as you execute vector and semantic search. You leverage the aggregate compute resources of the cluster for distributed and parallel computation of these demending queries. ## What We Are Watching LTAP is not yet generally available. Lakehouse//RT is in beta. The union read mechanism described here is based on published architecture documentation and independent engineering analysis, not production benchmarks. Databricks may publish performance characterization of the union read under concurrent write load, and if they do we will update our analysis accordingly. What is clear from the architecture is this: the union read is an elegant solution to a problem that a different architecture would never have. Databricks correctly identified that the fragmented data stack is the bottleneck for AI agents. LTAP is a meaningful step toward solving that problem for organizations already in the Databricks ecosystem. But bridging two engines at the storage layer, however cleanly, is not the same as building one engine that was designed to run all three workloads from the start. For architects making data infrastructure decisions for agent systems, that distinction is worth understanding before the design is set. --- # Press Release: RegattaDB Launches as the Database Built for AI Agents Source: https://regatta.dev/blog/press-release-regattadb-launches-as-the-database-built-for-ai-agents Published: 2026-07-15 Updated: 2026-07-22 Author: Boaz Palgi # RegattaDB Launches as the Database Built for AI Agents — Unifying OLTP, OLAP, and Vectors RegattaDB unifies transactions, analytics, and vector search in one database, giving agents a single source of truth at scale, while reducing infrastructure costs by 75%. New York, July 15, 2026 — Regatta Data today announced the general availability of RegattaDB, a distributed SQL database that unifies transactional, analytical, and vector workloads at scale, performance and efficiency. RegattaDB was built from the ground up to serve as the data foundation for AI agent systems. RegattaDB is available for production deployments as a managed cloud service (Regatta Cloud) or self-hosted on your own infrastructure. The company has raised $68M from Lightspeed Venture Partners, 83North, TPY Capital, alongside enterprises like Salesforce, Comcast, and Amdocs, and industry leaders Frank Slootman, Eyal Waldman, Bill Scannell, and Greg Lavender. The founding team previously founded or led data infrastructure software companies Topio (acquired by NetApp), XtremIO (acquired by EMC), Storwize (acquired by IBM), and ScaleIO (acquired by EMC, today Dell PowerFlex). ### The Legacy Data Layer Was Not Built for Agents Agents need to think, reason, and act on live data simultaneously, which means they need real-time execution of transactions (OLTP), analytics (OLAP), and semantic context (Vectors) across millions of concurrent instances. However, the lakes, warehouses, and siloed operational databases that power most enterprises today were never designed for this. They fragment context, introduce latency, and force complexity through the pipelines and integrations required just to keep data moving between them. Vendors have tried to solve this by bolting capabilities onto existing systems, but these approaches inherit that complexity rather than eliminate it. Solving a foundational architecture problem requires rethinking the foundation. ### One Database. One Concurrency Model. No Pipelines. RegattaDB is a single, unified SQL database that delivers distributed transactions (OLTP), real-time analytics (OLAP), and vector search simultaneously on the same data, efficiently at scale. It uses one distributed concurrency model that delivers serializable cross-node consistency and uncompromised performance for all three workloads. It eliminates the need for external pipelines or built-in synchronization layers. When those capabilities live in separate systems, agents struggle to collaborate, hallucinate, and are forced to work from an incomplete and inconsistent picture of the business. When they live in one system, agents can reason and act on a singular truth. ### Proven at Scale On 50 commodity cloud nodes, RegattaDB executed a distributed JOIN across 20 billion rows while sustaining 50,000 ACID-compliant transactional updates per second on the same dataset, with no indexes or data co-location optimizations, in just 3 minutes. The closest industry alternative would stream data from operational databases to a data warehouse and run the same query hours later. In a separate benchmark, RegattaDB delivered 20 times the performance per footprint of other distributed SQL databases. Also, RegattaDB's architecture enables 400% denser workloads per server compared to legacy single node databases, and eliminates an average of 75% of hardware, power, cooling, and space costs. AI agent workloads scale. Infrastructure costs do not. ### Deployed Across Telco, Finance, Retail, NeoCloud, and SaaS Regatta's deployments span telco, finance, retail and supply chain, NeoCloud, and SaaS. Synergy Logistics, a UK-headquartered supply chain software company recognized in the Gartner® Magic Quadrant™ for Warehouse Management Systems (WMS) for 14 years, has selected RegattaDB as the data layer for ORCA, its new hybrid WMS, to support high-throughput fulfillment operations that demand real-time multi-agent orchestration at scale. "As warehouse operations increasingly rely on real-time multi-agent orchestration and edge execution, legacy databases simply cannot keep pace with the massive concurrency demands," said Anish Mackan, CTO at Synergy Logistics. "By anchoring ORCA to RegattaDB, we provide high-throughput fulfillment centers with a modern data layer capable of handling intense, low-latency workloads without sacrificing reliability or speed." "When we started building Regatta, we had no idea the agent movement would become the next major wave in computing," said Boaz Palgi, CEO of Regatta Data. "What we did recognize was that the industry's data architecture had reached its limits. The same fundamental data-layer challenges that we saw years ago still exist today and agents are only magnifying them. We looked at the database as a storage and distributed systems problem and solved it from the bottom up. The result is a fundamentally different database architecture, and it is the only way to truly unify transactional (OLTP), real-time analytics (OLAP), and vector search at the scale, performance, and efficiency modern AI systems require." At the core of RegattaDB is a patented and proprietary distributed concurrency control protocol that enables fundamentally different workload types to run natively together across nodes boundaries without performance tradeoffs or consistency compromises. "What the Regatta team has built is not a patch on existing architecture. It is a rethink of the foundation," said Gil Goren, General Partner, 83North. "It is the only database that resolves the problem rather than moving it around. This team has done it before, and they have done it again." ### Industry Veteran Greg Lavender Joins Board of Regatta Greg Lavender, former Intel EVP and CTO and board member at Nutanix and Arista, is joining the Regatta Data Board of Directors to help drive the company's next stage of growth. With more than four decades of leadership across enterprise software, AI infrastructure, and cloud-scale systems, Greg has held senior technology executive roles at Intel, VMware, Citi, Cisco Systems, and Sun Microsystems, bringing deep expertise and industry relationships across the markets Regatta Data serves. --- # Databricks LTAP and the Unfinished Problem of Unified Data Source: https://regatta.dev/blog/databricks-ltap-storage-unification-is-not-enough Published: 2026-06-24 Updated: 2026-08-20 Author: Boaz Palgi Databricks made a significant announcement at Data + AI Summit this week. LTAP, or Lake Transactional/Analytical Processing, is their answer to a problem the industry has been trying to solve for decades: how do you run transactional and analytical workloads on the same data without paying for pipelines, replication, and the latency that comes with both? While the announcement is worth taking seriously, it is also worth reading it carefully. ## What Databricks Actually Shipped Lakebase, Databricks' serverless Postgres service built on object storage, is generally available. LTAP is the architectural concept layered on top. Rather than writing transactional data in Postgres format and running a CDC pipeline to convert it into columnar format for the Lakehouse, Lakebase now writes transactional data directly into Delta and Iceberg formats at the point of write via copy-on-write. The lake and the transactional layer share the same physical data from the moment it lands. It is a meaningful contribution, but is also, not yet available: LTAP itself is listed as coming soon and Lakehouse//RT, the Reyden compute engine that delivers sub-100ms analytical query latency on Delta and Iceberg tables, is in beta. ## Why HTAP Has Fallen Short (so far): Two engines in conflict The HTAP premise is a single system that could handle transactions, analytics, and semantic workloads without moving data between them. The problem is complex. OLTP workloads require low-latency random I/O for point reads and writes. OLAP workloads require high-throughput sequential scans across large data sets. Vector workloads require approximate nearest-neighbor search across high-dimensional embeddings. Putting any two of these on the same compute engine creates resource contention. Putting all three on the same engine exasperates this challenge. Further, OLTP requires data-layouts that will provide optimal good performance for transactions, and a variety of alternative data-layouts chosen by HTAP databases for analytics don’t work well for OLTP. The “transformation” of the data is a challenge, especially when you want the OLAP data to be completely current. Zero-ETL approaches and CDC pipelines were attempts to hide that contention by keeping separate systems but reducing the friction between them. Snowflake recently announced version of this solution. They don’t solve the underlying problem, they simply move it. ## Databricks LTAP is not HTAP LTAP takes a slightly different approach to HTAP but still doesn't address the combined engine challenge. Rather than forcing both workloads into a single execution engine, it keeps them separate: Postgres handles transactions, Spark and the Lakehouse handle analytics. What changes is the storage layer. The OLTP layer will “copy on write” and use buffers between it and the OLAP storage to eventually push data to the warehouse. ## Can LTAP Actually Run Complex Analytics and Transactions at Once? The answer to this question lies in the detail of this implementation and the Databricks announcement does not fully answer. From what we can gather (there is limited technical detail), in LTAP, Postgres writes to its WAL and buffer cache first, the caching layer then converts rows to columnar format, and then data lands in object storage in Delta or Iceberg format. The conversion step presents a concurrency question. There are two consistency domains in this architecture, not one. Postgres maintains ACID semantics on the transactional side. Delta Lake maintains snapshot isolation on the analytical side. Between them sits a caching and conversion layer that introduces a variable and unpublished flush window. A transaction that commits in Postgres is immediately visible to other Postgres queries. It is not visible to the Lakehouse analytical engine until it has been converted and flushed to object storage. Databricks describes data as "immediately queryable" but does not define what immediately means under load. A long-running Spark query reads from a snapshot as of the moment it starts. There are two potential problems here. First, transactions that commit in Postgres after that point are not visible to that query. Second, and more importantly, what happens if a transaction commits before the analytical query started and it is waiting to be flushed? This is a real concern. Further, even if the flush has started, there may be delay due to the transformation processing to the column store format. So ultimately, it is quite possible that the analytical query is not just out of date, but incorrect. Databricks has not published a bound on these potential issues yet. We merely call them out as challenges. This is a fairly important concern to investigate, especially as we look to use a unified database for agentic operations. An agent that needs to read live transactional state, run an analytical join across historical records, and execute a transaction based on the result is still crossing an engine boundary. LTAP removes the data synchronization cost of that crossing, but it does not remove the crossing. ## What about LTAP Performance? The benchmark numbers Databricks published for Lakehouse//RT are measured against TPC-H Q6: a single-table scan with filters and a simple aggregation. Q6 is a legitimate benchmark for scan speed, predicate pushdown, and vectorized execution. It does not test joins. The performance profile of complex multi-table analytical queries running concurrently with high-frequency transactional writes is not addressed by the published numbers. When Databricks says transactional and analytical workloads "scale independently," that is accurate and useful for many workloads. For agents that need both simultaneously within a single operation, independent scale means the coordination between engines still has to happen somewhere. In LTAP, that somewhere is application logic. ## The Third Workload LTAP Does Not Address: Vectors! Agent systems need three capabilities running simultaneously: transact on live operational data, reason analytically over historical patterns, and retrieve semantically similar context through vector search. LTAP attempts to ddresses the first two at the storage layer. Vector search remains an extension bolted to the Postgres transactional engine, with the contention and single-node ceiling problems being significant at any scale. These three workloads have fundamentally different compute profiles. A system that handles all three without degradation requires that the concurrency model be designed around all three from the start. LTAP gets the data into one place. ## RegattaDB: Unification Requires a New Architecture, Not a Rebuild The hardest problem with unification of OLTP and OLAP is the aligning on a single concurrency model. Most attempts at unification start with an existing system and extend it. Add a columnar store to a transactional database. Bolt a vector index onto Postgres. Connect an analytical engine to an operational one via shared storage. Each of these approaches inherits the architectural assumptions of the systems it started with. Those assumptions were made for different workloads, under different constraints, at a different time. Modifying them at the edges does not change what they are at the core. Running OLTP, OLAP, and vector workloads simultaneously without degradation requires rethinking how the database manages concurrent access, stores and retrieves data, handles version cleanup, and executes queries, from the storage layer through the query parser. RegattaDB was built from that constraint. A few specifics on what that means in practice: - Storage layout.RegattaDB uses a log-structured storage layout rather than slotted pages. This eliminates the read amplification that comes from sparse page layouts and avoids the TOAST indirection overhead Postgres carries for variable-size rows. Scans read only the data that is actually needed. - Version cleanup.RegattaDB Ranger technology maintains precise metadata about which row versions became unneeded at the moment a snapshot is removed. There is no crawling, no approximation, and no dependency on the oldest active snapshot. Long-running analytical queries do not stall transactional cleanup. OLTP and OLAP workloads run concurrently over the same data without inflating each other's version debt. - Index efficiency.RegattaDB indexes point to a stable Row ID rather than a physical storage location. Updates to non-indexed columns leave indexes untouched. This eliminates a compounding source of write amplification that is structural to Postgres. - Memory efficiency.RegattaDB uses logical caching at the row level rather than physical page caching. A frequently accessed 100-byte row occupies 100 bytes of cache, not the 8KB page it happens to share with cold data. At agent scale with large and interleaved working sets, this directly affects how many concurrent operations the system can sustain. - Scale.RegattaDB is designed for native horizontal scale. Distributed JOINs, cross-node transactions, and full ACID guarantees hold across node boundaries regardless of how data is distributed across the cluster. There is no sharding layer and no application-level compensation logic. - Concurrency model.Serializable consistency across distributed concurrent agent workloads is built into a novel concurrency control protocol that combines optimistic and pessimistic locking without the failure modes of either. This is not a feature layered on top of an existing engine. It is a design constraint that shaped every other architectural decision. The result is one schema, one connection, and one concurrency model across transactional, analytical, and vector workloads. Not three systems sharing a storage layer. One system, designed from the ground up to run all three. ## The Architecture LTAP Points To Already Exists The LTAP announcement reflects something the market has been moving toward for some time: the fragmented data stack is the bottleneck for AI agents. That is the right diagnosis, and we have been speaking of this for months. LTAP stops short as It does not produce a unified execution model, and for agent systems operating at scale, that distinction matters. RegattaDB was built to answer the full problem. Not by extending an existing engine or connecting two systems at the storage layer, but by rethinking the database from the ground up for exactly this workload profile: high-concurrency agent systems that need to transact, analyze, and reason semantically over the same live data, simultaneously, without routing across engines or accepting degraded consistency guarantees. That work is done. RegattaDB is in production, handling transactional, analytical, and vector workloads under a single concurrency model at scale. The architecture that LTAP points toward, one system, one concurrency model, no engine boundaries, is what RegattaDB delivers today. For architects evaluating data infrastructure for agent systems, the questions worth asking are specific: Does the system maintain serializable consistency across millions of simultaneous agent reads and writes? Does it scale linearly with agent concurrency without sharding? Does it handle transactional, analytical, and semantic workloads under a single concurrency model without routing across engines? Those questions have concrete answers. RegattaDB answers all of them. LTAP answers some of them. --- # We Rebuilt Our Website, Because We Rethought the Database Source: https://regatta.dev/blog/new-database-new-website Published: 2026-05-12 Updated: 2026-07-06 Author: Jim Walker Categories: Corporate News Things are moving fast. The market has shifted from "should we build agents" to "we are building and will need to deploy them at scale." And as these projects get to production, many realize that they are bottlenecked by the data layer beneath them. Addressing the limitations of the legacy data stack will separate teams that build and release something durable from those that spend the next two years refactoring. And the market knows this. It seems each week, we hear another database vendor or cloud provider propound that agents will need combined transactions and analytics at scale. While we agree with them, we take a slightly different tact at Regatta. Agents do need fresh data, consistent context, and a single view of the business. This framing is accurate, but how we resolve this is limited by their architectures of the underlying databases. Automated pipelines are still pipelines. New storage formats don’t solve concurrency mismatches. None of these approaches will make the data layer “agent ready”. ## The Data Challenge for Agents is Structural Months ago, inThe Shift to Agentic AI and a Modern Database (https://regatta.dev/blog/the-shift-to-agentic-ai-and-a-modern-database), we described the triangle problem that prevents legacy databases from being both transactional and analytical at the same time. This constraint shapes the data layer most enterprises run today: a transactional database handling live business state, an analytical system handling reporting, and pipelines moving data between them.Humans tolerate the latency that is introduced because humans are slow. Agents do not. There are three ways to approach the data layer for agent systems. - Context Layer on Existing Systems:Orchestrates queries across your current stack and an LLM interprets results. If the underlying systems are fragmented or stale, the intelligence layer inherits that directly. - Extend Existing Architectures:Where most are today. Reduce friction at the edges with transactional extensions to a warehouse, distributed SQL, and vector add-ons. The fragmentation at the center remains. - Rebuild the Data Layer:A single system handling transactions, analytics, and vector search natively with a shared concurrency model, no replication pipelines, and serializable consistency across all three. This is what RegattaDB is built on. ## What is the right database for Agents? RegattaDB RegattaDB is a rethink of the database from the storage layer up through to the concurrency model and parser to be applicable to both transactional and analytical workloads. And we extended the architecture to accommodate vector processing because modern workloads, like agents, need to avoid insight lag, duplicated data and inconsistencies. When we set off on our mission, the world had only dreamed of autonomous agents. It was sci-fi mostly. Today, we are in a new world where it seems that if you aren’t AI and agent based you are irrelevant. And while many scramble to add the “for AI” suffix to their taglines, we feel we have evolved with the market to be the right database at the right time for the right movement. By the way, we weren't entirely exempt from this ourselves. Our old website told a version of that story too: database first, AI angle bolted on. If agents are going to need to be more autonomous and “human-like” then they will need to think reason and act by themselves. They will need to coordinate with each other and they will need complete, up to the millisecond insight across important business context. They’ll need to do all of this in real-time and at scale. Every other database or pipelined architecture will struggle to deliver on these requirements. This new autonomous agent paradigm requires a fresh look at the underlying data sources, and that is what RegattaDB is. For many, including myself, this seems unattainable: serializable transactions and complex analytics at scale with acceptable performance. It isn’t, and we can prove it. Thebenchmarks are public (https://regatta.dev/blog/20b-row-join), and we would love toexplore this with you (https://regatta.dev/contact). The RegattaDB service is also available and if you want to run it, youcan start there (https://regatta.dev/contact). ## Same RegattaDB, new regatta.dev This is why we reworked regatta.dev. We didn’t just append a better AI story to our existing narative, but we started with the data requirements for Agentic AI and let the use cases follow from that. This new site is a V1 and we'll keep building and adding to it. But if you want to see how we think this fits into the modernization work happening in organizations right now, that's the place to start. We wouldlike to hear what you think (https://regatta.dev/contact). If something is unclear, missing, or lands differently than we intended, that feedback is genuinely useful to us. And if you are ready to try it, getting started is straightforward from there. --- # The Case for a Single, Distributed Database Under Growing Infrastructure Constraints Source: https://regatta.dev/blog/database-infrastructure-efficiency-ai-workloads Published: 2026-05-12 Updated: 2026-07-06 Author: Boaz Palgi TL;DR - RegattaDB runs four applications on the hardware you'd normally use for one, without pipelines, without extra licenses, and without replacing what you already have.Databases typically do one thing well. Transactional systems handle writes and live state. Analytical systems handle queries and historical data. Vector stores handle semantic search. Each is purpose-built, which means every application that needs more than one capability ends up running more than one system, with its own compute, storage, pipelines, and operational overhead. RegattaDB runs transactional, analytical, and vector workloads in a single engine, against the same data, at the same time. Applications no longer need a stack of systems to function. Data is not duplicated, compute is shared, and license costs collapse across the board. That unification is also what makes the platform possible. Because RegattaDB serves all three workload types from one layer, many applications can share a single cluster rather than each provisioning their own. Organizations run more on the same hardware, without fragmented per-application stacks. An executive mandate not to buy more servers, combined with real data center power and cooling constraints, makes a platform that runs 4x more applications on the same footprint a fundamentally different conversation. ## The Data Infrastructure Reality Enterprise data centers are sized for traditional workloads but now need to meet the demands of AI workloads they were never designed for. Power availability and cooling capacity have become genuine constraints, not theoretical. Hyperscalers are working through multi-year queues for power permits. Enterprise infrastructure teams are fielding executive mandates to expand AI capacity without expanding the physical footprint. At the same time, the arrival of AI has materially changed the cost conversation inside IT budgets. Teams that managed predictable server and storage spend now need to absorb new categories of cost with nothing offsetting them elsewhere in the budget. In the past year, supply chain challenges have more than doubled the costs of DRAM memory and NAND flash storage, with no relief in sight. Capital budgets are under pressure. The directive to do more with what you have is no longer a cost-reduction posture. It is a structural reality for most enterprise infrastructure organizations. ## RegattaDB: A Single Database Platform RegattaDB consolidates three categories of infrastructure into one and eliminates the pipeline and replication overhead that fragmented stacks require. The result is a single shared platform that runs more applications on the same hardware. Applications share the platform rather than each owning a copy of the infrastructure. This changes the economic model. Instead of provisioning three systems for every application, organizations provision one platform for all of them. Compute and storage are shared across applications rather than duplicated for each. A new application added to the platform costs a fraction of what it would cost to stand up its own stack. - Real-time insight and action in one step.Agents across all applications reason over context and commit transactions at the same time, without pipeline lag or stale reads. Every application on the platform operates from a single consistent business truth. - Power, cooling, and space constraints answered.More applications on the same physical footprint means infrastructure teams facing data center limits get a direct answer, without new servers, without new racks, without added power draw. - Land without migration risk.The platform does not require displacement of existing systems. Start with net-new AI agent applications. Prove the density on the same hardware. Expand from there as the value becomes clear. - Proven at scale.RegattaDB sustained 750,000+ transactions per second across a 50-node cluster at 98% efficiency with linear scale, while it ran a 20 billion row analytical join at the same time. No degradation between applications or workloads. ## Why 3–4x Density Is a Conservative Estimate Database servers in production environments are routinely provisioned well above their sustained utilization, often running at 20-40% of capacity on average to maintain headroom for traffic spikes, batch jobs, and unplanned load. That buffer is necessary but expensive, and given that traditional databases are confined to the borders of a single server, it is isolated per server. RegattaDB requires only 5-15% reserve capacity, leaving 85% available for active workloads. This difference compounds across a cluster. Because peak buffer resources are shared across the cluster rather than reserved per node, RegattaDB requires significantly less overprovisioning per server. The result is 3–4x higher workload density and 300–400% better hardware utilization than a conventional per-server architecture. Where 40 conventional database servers are needed to run a given set of applications, a 10-node RegattaDB cluster handles the same workload with headroom to spare and can absorb the peak demands of multiple applications simultaneously without contention. | | Conventional (40 nodes) | RegattaDB (10 nodes) | | --- | --- | --- | | Typical peak reserve per node | ~75% | ~15% | | Sustained utilization per node | ~25% | ~85% | | Application workloads per node | 1x | 3x | Conventional figures reflect a common production configuration where servers are provisioned for isolated peak demand. Actual utilization varies by workload and environment. In the above, each RegattaDB node runs the equivalent of 3x the application workload of a conventional node, with 10% additional headroom remaining. Across the cluster, 600% aggregate peak buffer is available which is sufficient to absorb about 12 applications each spiking 50% at exactly the same time. Result: 3–4× more applications on the same hardware, or the same applications on 75% fewer servers. ## Where Organizations Save Savings accumulate across every application that runs on RegattaDB. License costs fall when one contract replaces separate agreements across database, warehouse, vector, and integration vendors. Infrastructure costs fall when shared compute and a single storage footprint replace independent clusters multiplied across every application in the portfolio. Operational costs fall when one platform replaces the effort of maintaining pipelines, resolving data lag, and governing security across a different stack for each application. Cost growth becomes more predictable as each new application adds cost at the margin rather than from scratch. ## One Platform. Three Capabilities. RegattaDB runs OLTP (live transactions), OLAP (real-time analytics), and Vector (semantic reason) in a single storage layer with shared compute, built from the concurrency model up to handle all three without contention. Not stitched together. Not separately replicated. One platform, shared across every application, with one consistent view of the data underneath all of them. Infrastructure constraints in the modern data center are real. Power, cooling, and hardware availability will continue to shape what AI deployments are financially viable. Organizations that standardize on a platform that does more with the same hardware, without per-application sprawl, will find themselves with room to grow when their competitors are running out of it. That is the decision RegattaDB puts on the table. --- # What workloads can you converge with RegattaDB? Source: https://regatta.dev/blog/converged-workloads-regattadb Published: 2026-04-30 Updated: 2026-07-06 Author: Jim Walker ## The legacy data stack can’t keep up Databases are architected for one thing. You pick Postgres for transactions, Snowflake for analytics, Pinecone for vector search, then write the pipelines to connect them. This data architecture has worked for years, but it is inefficient and will not suffice for our agentic AI future. Agents will need to think, reason and act, all at once and in real-time. We’ll need to converge these workloads. The problem isn’t that any one of these tools are insufficient. Rather, they were built years ago and designed to optimize for a singular purpose: - OLTP databases can process live transactions but can’t evaluate it against behavioral aggregates or match it to historically similar patterns. - OLAP systems can surface those patterns but operate on stale, replicated data and can’t write enforcement actions back with consistency guarantees. - Vector database find semantic similarity but have no concept of live state or analytical history. When you need all three you’rerequiredto have pipelines, replication lag, and consistency bugs across system boundaries. RegattaDB combines OLTP, OLAP, and vector search in a single engine with a shared concurrency model. No replication pipelines. No cross-system synchronization. One place to read live state, run analytical queries, and search by semantic similarity. This unique, unified set of capabilities has been attempted but never accomplished, so identifying HOW to use converged workloads is a challenge for many. We just haven’t been able to dream of this in the past. ## Converged workloads that require OLTP, OLAP and Vector Below are some of the workloads where OLTP, OLAP, and vector need to operate together within a single transaction or agent loop. Separating them across systems isn’t just inconvenient, it breaks the use case entirely. Every organization has its own version of these problems, shaped by its own data, scale, and operational constraints. The examples here are a starting point for thinking about the art of the possible or of what becomes possible when the boundaries between types of workloads disappear. This is not an exhaustive map of where RegattaDB fits, rather it is inspirational. What converged workloads can you dream of? ### 1. Agent system orchestration and state management When you deploy agents at scale, state management becomes a reliability problem. Agents run concurrently, modify shared records, and fail. Without a way to checkpoint and resume, you lose context and visibility into what went wrong. RegattaDB gives you persistent, queryable agent state across an entire fleet. Every agent instance can checkpoint its current state, including memory context, task progress, and execution metadata. If an agent fails or is interrupted, it resumes from the last consistent checkpoint. TheOLTPlayer handles checkpoint writes and coordination under high concurrency with serializable consistency. TheOLAPlayer lets you query historical state transitions to find failure patterns and performance bottlenecks without needing a separate observability pipeline. Thevectorlayer lets you search across agent reasoning paths and decision traces to detect drift or find semantically similar past outcomes. This is not a monitoring tool layered on top of your database. Agent state is stored as operational data, and queryable the same way as everything else. ### 2. Hyper-personalized customer experiences Personalization systems often break down at the execution step. You can analyze what a customer is likely to want, but acting on that analysis in the same transaction requires crossing into a separate operational system. With RegattaDB, the analysis and the execution share a data layer. TheOLTPlayer holds live customer profiles, inventory, pricing, and cart state. TheOLAPlayer evaluates purchasing behavior, cohort trends, and margin data to determine which offer to make. Thevectorlayer finds products with similar attributes and purchase patterns to the customer’s history. You can evaluate context, decide on an offer, and write the transaction to the customer record in a single pass. There is no handoff between systems and no lag between insight and action. ### 3. Intelligent customer support Support personnel (or agents) perform better when they have access to both the customer’s current state and the full history of how similar problems were resolved. That combination typically requires querying two or three separate systems. RegattaDB gives support agents one place to check ticket status and entitlements (OLTP), analyze resolution patterns and escalation trends across historical data (OLAP), and run semantic search across past tickets, call transcripts, and knowledge base articles to find contextually relevant solutions (vector). The agent can update a case, issue credit, or trigger a workflow from the same system it used to look up the answer. ### 4. Network operations center automation NOC automation works best when you (or agents) can detect anomalies, compare them to prior incidents, and take corrective action without waiting on a human in the loop. That requires real-time signal ingestion, historical pattern analysis, and semantic similarity search, coordinated under transactional consistency. TheOLTPlayer tracks device state across a huge number of devices, configuration changes, and incident records as they happen. TheOLAPlayer correlates failures, latency patterns, and configuration changes to surface systemic risk. Thevectorlayer matches current anomaly signatures to historically similar incidents and their remediation steps. And with MCP, a resource could query incidents, in real-time, in the field and in their natural language. The result is a system that can move from detection to action within a single operational loop, with a complete audit record of everything it did. ### 5. Security incident detection and response Threat detection depends on behavioral baselines, pattern recognition, and fast enforcement. When those capabilities live in separate systems, there is lag between detection and response. RegattaDB maintains real-time security state in theOLTPlayer, including sessions, authentication events, permission changes, and device posture. TheOLAPlayer establishes behavioral baselines and evaluates deviations across users and systems. Thevectorlayer compares logs, alerts, and threat intelligence feeds to prior incident records to find attack patterns that rule-based systems would miss. An agent operating across this layer can detect a threat, evaluate its severity relative to historical incidents, and take enforcement action in the same transaction. ### 6. Fraud detection Fraud detection requires evaluating a transaction in real time, comparing it to behavioral patterns over time, and matching it against known fraud signatures. These are three different query types against the same data. TheOLTPlayer processes live transactions and enforces consistency at the moment of authorization. TheOLAPlayer evaluates velocity, geographic deviation, and behavioral aggregates to identify statistical anomalies. Thevectorlayer compares the current transaction sequence to embeddings of known fraud cases to catch patterns that fall outside explicit rules. All three happen without moving data between systems, which matters when the window for action is milliseconds. ### 7. Real-time risk and high-performance trading systems RegattaDB may not be a replacement for the purpose-built execution infrastructure that high-frequency trading requires. It is a good fit, however for the risk management, compliance, and analytical layers that sit alongside it, and in those layers, the architectural problem is the same one that appears everywhere else in this post: the data you need to make a decision lives in more than one system, and moving it between them costs you time and consistency you cannot afford. Risk evaluation, position analytics, and pattern-based signal detection are typically handled by separate systems and by the time data has moved between them, the basis for a decision has already changed. RegattaDB keeps all three query types on the same data. TheOLTPlayer maintains live position state, order books, and trade records with the consistency guarantees that financial systems require. TheOLAPlayer evaluates portfolio exposure, margin requirements, and risk aggregates in real time, without waiting for data to land in a separate analytics system. Thevectorlayer compares current market conditions and order flow patterns to historical analogs to surface signals that rule-based models would not catch. In an environment where the gap between what your data says and what your systems know about it has direct financial consequences, that architectural consolidation is not a convenience. It is a risk control. ## Converged workloads that require two of the three layers Not every compelling use case requires all three layers working simultaneously. These workloads are primarily two-layer problems, but they illustrate a different kind of value: eliminating the operational cost of maintaining two separate specialized systems with a synchronization pipeline between them. The benefit is simpler architecture and fresher data, not three-way query coordination. ### 8. Operational analytics on real-time inventory systems Traditional analytics stacks require you to replicate operational data into a warehouse before you can run analytical queries against it. For inventory, that means your analytics are always a pipeline delay behind reality. You might even know your stock levels as of thirty minutes ago, but not right now. RegattaDB lets you runOLAPqueries directly against live operational inventory data. TheOLTPlayer holds current stock levels, reservation state, and fulfillment records as transactions happen. The OLAP layer runs aggregations, trend analysis, and demand forecasting against that same data without waiting for a replication cycle. The result is analytical queries that reflect the actual current state of your inventory, which matters when you are making pricing decisions, triggering reorders, or managing allocation across a large number of SKUs at scale. ### 9. Semantic search on real-time data Vector search is typically implemented against a pre-indexed snapshot of your data. That works well when the underlying data is relatively static, but breaks down when freshness matters. A semantic search over customer records, support tickets, or product listings that were indexed an hour ago may return results that no longer reflect reality. RegattaDB lets you run semantic search against data that is current at index time. TheOLTPlayer ensures the records being searched reflect live state. Thevectorlayer runs similarity queries against that data without requiring a separate indexing pipeline or accepting a freshness tradeoff. This matters most in environments where data changes frequently and users expect search results to reflect the most current state of the world. ## The common thread: workload convergence Every use case above demonstrates the cost of moving data between specialized systems. Sometimes that cost shows up as broken transactional consistency across three query types. Sometimes it is the quiet tax of pipelines, replication lag, and the organizational overhead of keeping multiple systems honest with each other. Either way, the legacy architecture is constraining what you can build before you have even started designing it. Stitching together best-of-breed systems was a reasonable answer when workloads were predictable, and we functioned at human scale. With agents, this is no longer reasonable. The coordination overhead, the consistency gaps, and the latency are not engineering problems that can be oprtimized. They are structural limitations of the architecture itself. The most compelling reason to explore RegattaDB is not any single use case. It is the question of what becomes possible when the constraint disappears entirely. When live state, historical patterns, and semantic similarity are always available together, in the same query, against the same data, the design space for what your systems can do changes. Problems that required workarounds become tractable. Use cases that were too complex to justify become straightforward. The examples in this post are meant to open that door, not to define what is on the other side of it. --- # NVIDIA’s Agentic Era: The Bottleneck Isn't GPUs, It’s Your Database Source: https://regatta.dev/blog/nvidia-s-agentic-era-the-bottleneck-isn-t-gpus-it-s-your-database Published: 2026-03-19 Updated: 2026-07-06 Author: Jim Walker Categories: Platform, Technology SUMMARY: The Shift to Agentic AI is real: Moving beyond basic LLMs, the Agentic Era focuses on AI systems that can reason, coordinate, and execute complex real-world transactions. - The Data Bottleneck: While GPUs provide the engine, the primary obstacle to AI autonomy is the database layer, which must provide a truth for agents to act upon. - Transactional Integrity: To prevent “hallucinations” in execution (like double-selling inventory), AI agents require strict serializable isolation and real-time data consistency. - RegattaDB Performance: TPC-C benchmark shows RegattaDB maintains linear scale and 98% efficiency even at extreme scales (1.5 million warehouses), and delivers the throughput needed for massive AI agent systems. - Context Fabric for Agent Systems: RegattaDB acts as a shared memory layer, allowing AI agents to collaborate on the same data without state drift or conflicts. In Monday’s GTC 2026 keynote, Jensen Huang highlighted that the next phase of the AI gold rush is agentic systems. He also called out thatthere needs to be a massive $120B expansion in spend on data infrastructure (https://www.youtube.com/live/jw_o0xr8MWU?si=gR9iOfnlwv0II7gw&t=981)to make structured data usable for these new agent systems. His argument is that while LLMs are the “engine,” structured data is the “ground truth.” For AI agents to actually perform work (like managing a portfolio, processing insurance claims or managing supply chains), they need a high-performance, real-time data layer that can handle massive transactional loads without collapsing and with high integrity. We agree… RegattaDB plays directly into this pillar of NVIDIA’s ecosystem. Why RegattaDB is the Ground Truth for NVIDIA’s Agentic Era As NVIDIA moves from selling individual GPUs to selling entire AI Factory racks (like theVera Rubin NVL72 (https://nvidianews.nvidia.com/news/nvidia-vera-rubin-platform)), the bottleneck shifts to how fast a database can record the actions of thousands of concurrent AI agents and then allow them to reason over this collective live operational data. The value of RegattaDB maps directly to the specific mechanics of an NVIDIA-powered agentic ecosystem: - The Agent Execution Engine: Think, Reason, ActRegattaDB transforms AI from a chatbot into a thinking and transacting entity. It delivers serializable isolation at massive scale and allows agents to perform complex analysis and guaranteed state changes on the same operational data. When an agent reasons about an inventory adjustment and then acts, RegattaDB ensures Jensen’s “ground truth” remains current and immutable with transactional integrity. - An Agent Context Fabric: Memory, Collaboration, and CoordinationAs Jensen noted, AI “swarms” require a high-performance data layer to prevent state drift. RegattaDB acts as a linearizable memory layer, providing the shared state necessary for multiple agents to coordinate on complex projects without overwriting each other. It serves as the “common ground” for both short-term context and long-term history within the AI Factory. - Agentic Scale: Efficient PerformanceTo justify the $120B CapEx of a Vera Rubin deployment, infrastructure must be hyper-efficient.RegattaDB delivers 12.6 tpmC (98% efficiency) (https://regatta.dev/blog/regattadb-tpc-c-benchmark-750k-tps-1-5m-warehouses/), eliminating the latencies and costs of moving data between silos. By unifying transactional, analytical, and vector reasoning in a single database, it provides the performance and efficiency density required as agentic data volumes explode. The future is today, we have technical proof The last point above is critical. We can build intelligent agent systems, but if they don’t scale with efficiency, they’ll never become a reality. And if we build on our legacy data architectures, these modern agent systems will only inherit their limitations. Over the past few months, we posted a few blog posts that speak to how we can scale both transactions and analytics at the same time. First,we published an in depth demo of a complex 20B row analytical join at the same time as the database was executing 50,000 transactions per second (https://regatta.dev/blog/20b-row-join/). Second, we pushed a post that provides technical breakdown of a TPC-C benchmark that showed how RegattaDB can maintain 98% efficiency under the extreme concurrency Jensen described in his keynote. The results provide a concrete proof point for how RegattaDB handles the data gravity problem Jensen described. As NVIDIA transitions from Blackwell to the Vera Rubin architecture, the focus shifts toward computational density. As agent systems scale, they will need to get more work done per rack with lower power overhead. And as the supporting structured data for these NVIDIA-powered stacks get built out, the RegattaDB ability to maintain high efficiency at extreme scale becomes a primary competitive advantage. His comments map directly to results we outlined in this benchmark. ### What is the bottleneck in Agentic AI? | Jensen’s “AI Factory” Requirement | Regatta Performance Metric | | --- | --- | | Agents Execution (think, reason and transact | 20B Row Join w/ 50K transactions | | High Throughput (Feeding the GPU) | 750,000+ Transactions Per Second | | Extreme Scale (Global Data Ecosystem) | 1.5 Million TPC-C Warehouses | | Resource Efficiency (Lower TCO/Power) | 98% Efficiency on 50-node Cluster | | Growth (Modular Expansion) | 12.6 tpmC per warehouse (Linear) | ### Benchmark Insight 1: Massive Concurrency without “Thrashing” While traditional databases hit a performance degradation under parallel requests, RegattaDB eliminated contention in a 1.5 million warehouse environment. Maintaining 98% efficiency across 50 nodes ensures CPU cycles are spent on processing rather than internal coordination. For Vera Rubin deployments, this translates to maximum ROI on NVLink interconnects by removing the database bottleneck and allowing for linear scale. ### Benchmark Insight 2: Linear Scale for “AI Factories” NVIDIA’s $120B modular vision requires a data layer that scales in lockstep with Grace Blackwell or Rubin units. RegattaDB demonstrated a consistent 12.6 tpmC per warehouse as the cluster grew, providing the linear predictability enterprise architects need. This guarantees that doubling hardware spend actually doubles transactional throughput for AI agents. ### Benchmark Insight 3: Real-Time Consistency for Agentic Actions Consider a supply chain agent managing 10,000 concurrent purchase orders across a global warehouse network. At step 3 of a 12-step fulfillment workflow, the agent reads inventory levels, but a legacy database serving stale data shows 500 units available when 480 have already been committed by parallel agents. By step 12, the agent has confidently confirmed shipments it cannot fulfill, triggering cascading failures across downstream logistics, finance reconciliation, and customer SLAs. This isn’t a hypothetical. It’s the default behavior of any database that can’t guarantee serializable isolation under high concurrency. Without a ground truth that is both real-time and consistent, AI agents don’t just make mistakes, they manufacture confidence in those mistakes. To prevent agents from using stale or incorrect data, like the example above, strict serializable isolation is non-negotiable. Achieving 750,000+ TPS under strict serializable isolation proves RegattaDB can serve as the system of record for NVIDIA’s vision. It ensures every agentic decision is recorded instantly and accurately across the global fabric. Further, execution of a massive, complex analytical join at the same time as you commit 50k transactions per second demonstrates that RegattaDB can both act and think at the same time, on the same live operational data. The future of Agentic systems is live context The move toward autonomous AI agent systems requires a fundamental rethink of the data layer that these systems are built on. Simple adoption of legacy infrastructure will not suffice as agents will need reasoning and real-time execution in real-time. They need a reliable, operational truth of the current state of the business delivered through strict serializable isolation, ad-hoc large scale analytics and linear scale. RegattaDB addresses this gap and helps turn the NVIDIA “AI Factories” into actionable execution engines. Ready to benchmark RegattaDB against your agent workload? Start here ->info@regatta.dev (mailto:info@regatta.dev) --- # RegattaDB TPC-C Benchmark: 750,000 TPS Source: https://regatta.dev/blog/regattadb-tpc-c-benchmark-750k-tps-1-5m-warehouses Published: 2026-02-24 Updated: 2026-08-04 Author: Jim Walker Categories: Platform, Technology This post documents a TPC-C benchmark for RegattaDB at 1.5 million warehouses across 50 GCP nodes, sustaining over 750,000 transactions per second at 98% tpmC efficiency. We provide full visibility into CPU utilization, memory pressure, NVMe disk I/O, and per-transaction latency percentiles throughout the workload. The goal is to show not just what the numbers are, but what they mean for teams evaluating distributed OLTP databases at extreme concurrency and scale. We ran this benchmark in isolation. RegattaDB can do this while simultaneously running analytical queries which is something we demonstrate separately. But first, the transactional numbers. Key results at a glance: - Scale: 1.5 Million TPC-C Warehouses - Throughput: 750,000+ Transactions Per Second (TPS) - Efficiency: 12.6 tpmC per warehouse (98% of theoretical max) - Infrastructure: 50-node GCP deployment (Local NVMe SSDs) What Is This Benchmark and Why Does It Matter? Performance numbers are easy to publish and hard to interpret. We ran this benchmark to answer a practical question: how does RegattaDB behave at massive scale under sustained, realistic transactional load over time and under contention? We wanted to push our TPC-C testing to the limit, but we will also publish a more “normal” workload (200k warehouses) in the next few weeks. What is TPC-C?TPC-C is a transactional benchmark designed to stress concurrency, coordination, durability, and latency under sustained transactional (OLTP) load. While many published results focus on peak throughput, fewer demonstrate how systems behave when pushed to extreme scale with realistic concurrency and storage pressure. Test Configuration: 1.5 Million TPC-C Warehouses at Scale We evaluated RegattaDB using a distributed deployment designed to reflect production usage rather than an idealized lab setup. The goal was not to produce the highest possible score, but to observe stable behavior under realistic conditions. In TPC-C, the number of warehouses is the primary scale factor. Increasing warehouses grows: - The relational dataset - The number of concurrent terminals - Locking and coordination pressure across hot tables For this run, the database is pre-populated with 1.5 million warehouses. At this scale, the total data footprint works out to just over 11 MB per warehouse. While we executed smaller configurations with full population at maximum capacity, for this 50-node cluster, a lighter population method was employed to reduce costs while fully maintaining the transaction load rate and ensuring representative results. Cluster Specification: 50-Node GCP Deployment with Local NVMe SSDs - Nodes: 50x z3-highmem-44-lssd (GCP) - 44 vCPUs (22 physical Intel cores with hyperthreading) - 352 GB RAM - 9 TB of local SSD storage across three devices - OS: Red Hat Enterprise Linux 8.10 In total, the database spans 150 local NVMe SSDs, all actively participating in the workload. TPC-C Throughput Results: 750,000+ TPS at 98% tpmC Efficiency An internal RegattaDB monitoring tool shows the system sustaining over750,000 transactions per secondduring peak execution. This level of load is where many systems encounter contention collapse, coordination bottlenecks, or tail-latency spikes. In this run, RegattaDB maintains stable execution while continuing to process transactional bursts at scale. Throughout the run, the monitoring dashboard confirms that the 50-node cluster: - Is actively executing a 1.5 million warehouse TPC-C workload - Sustains12.6 tpmC per warehouse (which equals ~98% efficiency) - The cluster remains stable under continuous load What is tpmC?tpmC is a very specific and significant “magic number” in the TPC-C benchmark. It represents a theoretical maximum throughput allowed per “warehouse” in the test. If a database produces 12.8 tpmC per warehouse, it mean the database is running at ~99% efficiency. You are getting the absolute maximum performance possible out of your data setup. We measured resource utilization across the cluster during the run and peak vCPU utilization per node is 42 (out of the configured 44 vCPUs). TPC-C workloads are inherently cyclical. Terminals submit transactions, wait for completion, and then pause for mandated think time. This pattern is visible across hTOP, showing CPU utilization rising during transaction bursts and dropping during think time intervals and nmon, capturing how RegattaDB absorbs sharp load spikes without instability. The system is not artificially smoothed or rate-limited; it processes the natural concurrency waves produced by 1.5 million active warehouses. Despite hundreds of gigabytes of memory per node, the working set at this scale exceeds RAM capacity. As a result, the workload drives sustained, high-volume disk reads and writes per node, reflecting real operational pressure rather than transient bursts or synthetic throttling. The I/O profile closely mirrors the transactional cycles of TPC-C, indicating that storage is meaningfully exercised rather than bypassed through aggressive caching. Transaction Latency Percentiles (p50–p99) Across All TPC-C Transaction Types Finally, we measured p50, p90, p95 and p99 latencies for each transaction type. TPC-C is fundamentally a concurrency and tail-behavior test, not just a throughput test and its main measure tpmC can hide instability. Percentile latencies expose behavior under real contention, and each level is important to consider for each of the transacting tables. (Note: further improvements are in progress always.) TPC-C Transaction Latency by Percentile: RegattaDB at 1.5M Warehouses (milliseconds) | | p50(ms) | p90(ms) | p95(ms) | p99(ms) | AVG(ms) | | --- | --- | --- | --- | --- | --- | | New-Order | 39.4 | 123 | 325 | 640 | 66.6 | | Payment | 19.8 | 30.8 | 38.4 | 47.5 | 21.1 | | Order-Status | 19.8 | 30.2 | 30.2 | 40.2 | 17.0 | | Delivery | 213 | 986 | 988 | 992 | 458 | | Stock-Level | 29.6 | 40.2 | 41.1 | 53.3 | 25.3 | Watch the Full Benchmark Run on YouTube We capture the run on a video that highlights some of these key points and uses a little magic to fast forward through various waits. You canview it on our YouTube channel (https://youtu.be/iOz37FHI-PU). Embed: https://www.youtube.com/embed/iOz37FHI-PU?feature=oembed https://www.youtube.com/embed/iOz37FHI-PU?feature=oembed RegattaDB internal monitoring dashboard showing sustained 750,000+ transactions per second during a 1.5 million warehouse TPC-C benchmark run on a 50-node GCP cluster What These TPC-C Results Actually Mean This run demonstrates RegattaDB executing a classic OLTP benchmark at a scale rarely shown publicly. This does not take into consideration that RegattaDB could handle analytical queries while these transactions are being committed. The report provides full visibility into system behavior under load. Rather than optimizing for a narrow peak result, the system sustains transactional execution across millions of warehouses, hundreds of thousands of concurrent transactions, and active disk I/O. Also, TPC-C results are often misread when reduced to a single throughput number. A few clarifications are important: - Warehouses matter as much as tpmCThroughput at 1.5 million warehouses implies vastly higher concurrency, data volume, and coordination pressure than runs at smaller scales. - This is a sustained run, not a peak measurementThe reported throughput is maintained while meeting TPC-C think time and transactional semantics. - Hardware context is explicitResults reflect performance on 50 high-memory, local-SSD nodes. Absolute numbers should be evaluated relative to hardware cost and configuration. OLTP and OLAP Simultaneously: What RegattaDB Can Do Beyond This Benchmark These results characterize transactional performance under extreme concurrency. They do not measure analytical queries or mixed OLTP/OLAP workloads that RegattaDB can also deliver. In fact, we can execute massive analytical workloads at the same time as we sustain continuous transaction. We recently published apost that demonstrates this using a JOIN across two 10 billion row tables while we sustain 50,000 UPDATES (https://regatta.dev/blog/20b-row-join/)per second. Why We Publish CPU, I/O, and Latency: Not Just tpmC Also, we feel transparency matters so we not only publish the high level tpmC number, but also add CPU, I/O, concurrency and latency metrics, which allows you to better reason about system behavior rather than relying on aggregate scores alone. For teams evaluating databases for high-concurrency, large-scale transactional systems, especially those supporting modern microservices or agent-driven workloads, this benchmark provides a concrete reference point grounded in observable system behavior. Soon, we will publish a benchmark for a more mundane 200K warehouse run, so stay tuned as that will drop soon. Also, if you are running a benchmark of your own or evaluating databases for your application, we’d be happy to connect to see if RegattaDB fits your architecture. Contact us atinfo@regatta.dev (mailto:info@regatta.dev) --- # File under “now possible”: A 20B row JOIN and 50,000 UPDATES/second in a single distributed database Source: https://regatta.dev/blog/20b-row-join Published: 2025-12-29 Updated: 2026-07-29 Author: Jim Walker Categories: Platform, Technology Distributed joins are among the most demanding operations in large‑scale data systems. Trying to do this at the same time as transactions are being committed is an incredible challenge that many databases simply cannot execute; let alone return results in an acceptable time. To demonstrate how RegattaDB can meet this challenge, we implemented a scenario that removes common optimizations and exposes the system’s raw execution capabilities. It joins 20 billion rows, across 50 small cloud nodes, with no indexes, while executing 50,000 ACID‑compliant updates per second on the same data. ## What we set out to prove: three constraints Our goal was to show how RegattaDB could handle both OLTP and OLAP workloads simultaneously. We use three hard constraints to test this ability. Most databases can handle one or two of these, but none can do all three. Note that we do not set performance as a constraint as the three constraints alone are difficult enough. RegattaDB also delivers query results in an acceptable time, but that is not defined as a constraint, per se. Large‑scale, complex distributed joins Concurrent transactional writes using strong consistency (serializable) Random data distribution with no locality advantages ## The data model and data distribution across the cluster We made up a fairly simple data model to test these constraints. We have defined a Customers and an Orders table. The test performs updates while executing a join that will look for all “foreign orders”. Basically, we will look for all the orders where the region id of the store in which the transaction took place does not match the region id of the customer. We will also count types of payment for these as well. More about the JOINs is described below. To support this, we created two tables and populated each with 10 billion rows. For the test,CustomerIDis used for our join key,RegionIDis used for the “foreign order” comparison andPaymentMethodis used for aggregation. Also, there are no secondary indexes defined for either table. ```sql CREATE TABLE Customers ( CustomerID BIGINT, Name VARCHAR(100), ZipCode BIGINT, PhoneNumber VARCHAR(20), LoyaltyLevel BIGINT, RegionID BIGINT ) ``` ```sql CREATE TABLE Orders ( OrderID BIGINT, CustomerID BIGINT, StoreId BIGINT, OrderYear BIGINT, Amount BIGINT, ProductID BIGINT, Quantity BIGINT, OrderDate BIGINT, PaymentMethod BIGINT, StoreRegionID BIGINT ) ``` ## Random distribution of data across the cluster We populated the 10B rows for each table and ensured the data for both tables was randomly and evenly distributed across the 50-node cluster so that there was no sharding onCustomerID, no affinity rules, and no attempt to co‑locate related rows. As a result, the chances for an order row and its corresponding customer row to land on the same node is roughly 1 in 50. So a vast majority of the joined rows require actual data movement among the nodes, with no shortcuts. Also, to force full scans, we disabled all index use. Additionally, we chose predicates that cannot be optimized by predicate-pushdowns, thus forcing all the 10B row pairs to be truly joined. This ensured that the JOIN had to: - Scan all table fragments - Propagate left and right sub-rows among nodes (many to many) - Construct approximately 10B join pairs at runtime Ultimately, this tests the fundamental throughput and coordination of RegattaDB, not the quality of how the user defines the indexes within the data model in RegattaDB. ## Cluster configuration For this test, we created a 50-node cluster of RegattaDB in GCP using small cloud instances (n2-highmem-8). Each instance had 8 vCPUS with 64GB RAM and 375 GB SSDs. We then deployed the 50 instances of RegattaDB to this environment. ## Concurrency Constraint: 50,000 serializable updates/second Before we initiated the JOIN, we kicked off a process that will continuously execute 50,000 ACID‑compliant updates per second. We wanted to prove that even with the long‑running scans and network shuffles of the JOIN, the system can maintain serializable isolation, external consistency, and acceptable commit latency for all transactions. We chose UPDATES so that the database would have to not only find each row but also conflict with the 20B rows that are participating in the JOIN at the same time. Ultimately, this tests the ability to run both OLTP and OLAP at scale. The process executes the following updates using a script that defines therandom_row_idfor each iteration and ensures there are 50,000 transactions per second. The correspondingrow_idthat is used is an internal concept that allows us to efficiently get to a record. The purpose of this test is to demonstrate the JOIN speed and less about the update, so we use this out of convenience. ```sql update orders set Amount = 1 where rowid = random_row_id; update customers set LoyaltyLevel= 1 where rowid = random_row_id; ``` ## The 20B row JOINs For this test, we defined two JOINs that require the intermediate creation of approximately 10B virtual rows each containing a sub-row from the right table and a sub-row from the left table where the right table’s sub-row and the corresponding left table’s sub-row are not originally stored in the same node. To force that to happen, the predicate used by the JOIN only compares fields from the right table and the left table, so one cannot “filter out” rows ahead of time. In RegattaDB, when you JOIN a large number of right and left sub-rows that are not collocated on the same nodes, a many-to-many propagation of the data occurs so that the matching left and right sub-rows land on the same node and the JOIN data is ultimately spread evenly across many nodes. ### JOIN 1: Identify “foreign” orders ```sql SELECT count(*) FROM Customers c JOIN Orders o ON c.CustomerID = o.CustomerID and c.RegionID != o.StoreRegionID; ``` A foreign order is one where:Customers.RegionID != Orders.StoreRegionIDand we designed the synthetic data so that roughly 100 million orders meet this condition. So, to answer this question, the database must: - Scan customers and orders in parallel - Propagate the right sub-rows and the left sub-rows across the network, so matching left and right sub-rows meet on the same node - On each of the node, identify matching left and right sub-rows and join them - Evaluate the predicate on the joined rows - Emit matching rows for downstream processing This is a classic distributed join followed by a cross‑table predicate evaluation. ### JOIN 2: Group foreign orders by payment method From the JOIN 1 output where we find all “foreign orders”, we then add to the query and calculate the number of foreign orders in each of the different payment methods for these. ```sql SELECT o.PaymentMethod, COUNT(*) AS order_count FROM Customers c JOIN Orders o ON c.CustomerID = o.CustomerID AND c.RegionID != o.StoreRegionID GROUP BY o.PaymentMethod; ``` Even though the group‑by is small relative to the join, it validates that the pipeline operates end‑to‑end without bottlenecks. ## The Results We executed these queries a few times and the results were clear: Not only can RegattaDB handle this workload, but it does so with incredible performance. Again, this is two 10b row tables, a complex join and with 50,000 updates happening concurrently. - JOIN 1: 174.613 seconds - JOIN 2: 181.929 seconds Below, we include anedited video to demonstrate (https://youtu.be/dM9h5-FJg1U)the execution. Thefull, unedited version (https://youtu.be/2irWCLG1DnA)is also available. Embed: YouTube video player https://www.youtube.com/embed/dM9h5-FJg1U?si=DIOL5Brj47KRPFfZ ## Why This Matters Many analytical queries involve large tables and complex joins; however, it has been nearly impossible to execute these within a distributed database that is guaranteeing transactional writes at the same time. This demonstration illustrates that this is not only possible in RegattaDB, but it can also be accomplished without the need for specialized hardware, manual tuning, or tightly controlled data layouts. For organizations that need to manage rapidly growing datasets, these capabilities translate into tangible benefits. They reduce operational overhead, lower infrastructure costs, and enable the simultaneous support of transactional applications alongside analytical queries. Additionally, they minimize restrictions on schema design, indexing strategies, and read patterns, giving teams greater flexibility and efficiency in handling diverse workloads. Want to see this live?Let us know! (https://regatta.dev/contact/) --- # The Shift to Agentic AI and a Modern Database Source: https://regatta.dev/blog/the-shift-to-agentic-ai-and-a-modern-database Published: 2025-12-16 Updated: 2026-07-29 Author: Jim Walker Categories: Platform, Technology ## Agents need to both think and act The core objective of Agentic AI is to deliver systems capable of executing functions that are generally associated with human intelligence, such as reasoning and learning. The long-term goal is to make them exhibit human-level cognitive abilities, so agents can adapt to situations without requiring task-specific programming. As Agentic AI evolves, we need agents that will both think and act. We need a database that supports both real-time operational transactional and ad-hoc analytical workloads. Intelligent transactions can’t wait for a complex analytical query to run in one system and have delayed results sent to another just to gain insight. Agents need to be able to ask ANY questions, not just predetermined queries and views. They can’t rely on relatively slow (and incredibly complex/brittle) data movement. They’ll need a single relational database for both transactions and live analytics, and we’ll need all of this at scale. Over the years, many have tried to combine OLTP and OLAP into a single database solution. However, all previous attempts encountered the “triangle problem,” where trade-offs among three primary system constraints are required: - Speed(Performance): The rate at which operations (transactions and analytics) can be processed. - Scale(Size): The capacity to handle ever-increasing volumes of data and user concurrency. - Efficiency(Cost/Budget): The operational cost relative to the resources consumed. Optimization for all three constraints without compromise has proven to be a massive challenge, especially with the added constraint of strong distributed ACID compliance for a relational database. ## Is a database an extremely complex storage system? Some doubt the plausibility of a combined, distributed OLTP/OLAP relational database. It is an intriguing problem that some have attempted to solve. The Regatta team, however, has taken a fundamentally different approach and has rethought the solution from the ground up. Unlike other recent database innovations that look at a database as solely a compute problem, Regatta relies heavily on innovations at the storage layer of the database combined with a wholly new and extremely efficient concurrency control protocol. This shift in approach is the natural progression of the team’s experience over the last couple of dozen years. We are pioneers of the “Software-Defined” revolution. While at ScaleIO, we proved that intelligent software could replace specialized hardware and turn commodity servers into enterprise-grade storage. At XtremIO, we helped normalize the idea of the “All-Flash Data Center.” We have a fairly large amount of experience designing and building scale-out, efficient distributed storage solutions. This collective experience in designing efficient, scalable systems provides the foundation for a novel storage-centric design in RegattaDB, which allows it to address the constraints of the traditional “triangle problem”. ## RegattaDB: Distributed SQL for Agentic AI RegattaDB allows you to execute complex, ad-hoc analytics on live transactional data. It delivers a distributed SQL database where guaranteed, cross-node, consistent transactions and complex analytical queries can co-exist, all without compromising performance and with extreme efficiency. Further, it incorporates vector database capabilities and is a distributed database that helps you scale easily and guarantee resilience. This combination of capabilities delivers a database that allows our modern AI agents to not just transact, but to reason using current and complete context. It enables these core Agentic AI functions that were once unthinkable: - Transactions: Extremely efficient, scale-out coordination of actionsRegattaDB implements apatented transaction/concurrency control (https://regatta.dev/blog/regattas-concurrency-control-protocols/)model that efficiently guarantees serializable isolation for distributed transactions. This helps agents coordinate with each other and more importantly to ensure there are no conflicts between them. Further, it dramatically improves performance and cost efficiency of the database, while still being able to deliver easy scale and guaranteed resilience.TPC-C Benchmark: As proof of these gains, we recently ran the TPC-C benchmark against 200,000 warehouses within the 99% threshold of 12.86 tpmc using only 10 nodes with 14 cores each. This typically represents cost savings of about 2,000% over the published results from other distributed databases. - Contextual Reasoning: Complex analytics on live transactional dataThe unique transactional model implements a locking mechanism for isolation that does not block analytical queries. It maintains intelligent point-in-time images and coordinates with the storage layer of the database to efficiently manage these. This ability to analyze live transactional data in real time provides instant and complete context to agents so they can make immediate, informed decisions.20B row join without indexes and with 50,000 concurrent transactions per second (https://regatta.dev/blog/20b-row-join/): To demonstrate single OLTP/OLAP capabilities, we executed a complex JOIN of two 10 billion row tables where the left and right sub-rows all live in different nodes and evaluation of the JOIN requires predicate processing between the left and the right. In parallel to the JOIN, we also pushed 50,000 updates per second randomly across the rows. We ran this experiment on a cluster of 50 small instances, each with 64G and 4 cores. While most databases would be challenged to execute the JOIN alone, RegattaDB returned results in 174 seconds and successfully completed all the updates in parallel. - Free Thinking: Ad-hoc, Natural Language QueriesRegattaDB provides incredible performance for analytical queries and can even deliver acceptable performance for those queries that do not take advantage of explicit indexes or predicates. This is critical for free thinking agents and allows individuals (or agents) to “dream up” ad-hoc queries without deep knowledge of database constructs. And with a native MCP server, RegattaDB allows any person or agent to use natural language to create and execute these random queries on live “fresh” transactional data. ## Agentic AI demandscost efficiencies The triangle challenge is real, and RegattaDB has addressed its challenges. It is also extremely resource efficient and high performant. It presents a Distributed SQL database without the gabby consensus protocols, so it is much cheaper to run than traditional Distributed SQL solutions, yet you still gain the benefits of consistent transactions at high performance, easy node-based scale, natural resilience and reduced data architecture complexity. And with single node databases, they generally require you to overprovision server resources to allow for traffic spikes and growth. RegattaDB allows you to use all cluster-wide free resources to accommodate these concerns, so there is no need to overprovision an individual node, delivering on average a 3-4x better footprint efficiency. This single OLAP/OLTP database also helps eliminate costly and brittle ETL and add-on services that increase complexity and latency in your data architecture. It eliminates the tangled mess of data movement and reduces the time it takes for your team to gain insight from business data. It’ll save time troubleshooting these layers and reduce operational costs. Finally, it will allow for net new agentic applications to be created that will more closely mirror human intelligence so you can dream bigger, grow your business and outpace competition. ## Agentic AI demands complete context Humans can reason because we can act on live data. Every action can be input into the next. Agents will need to act this way. At its simplistic best,RegattaDB (https://regatta.dev/blog/regattas-architecture-a-birds-eye-view/)allows your agents to perform ad-hoc queries on live transactional data so they can reason and act, all with complete context… more human like. --- # RegattaDB: Concurrency Control - Serializable Isolation Without Locks, Snapshots or Clock Sync Source: https://regatta.dev/blog/regattadb-concurrency-control-serializable-isolation-without-locks-snapshots-or-clock-sync Published: 2025-05-29 Updated: 2026-07-09 Author: Erez Webman Categories: Platform, Technology ## Introduction In this post, we’ll cover how RegattaDB’s concurrency-control protocols (CCPs) enable full serializable isolation in a distributed database — without distributed locks, without consistent snapshots, and without the transaction aborts that plague most optimistic approaches. If you’re evaluating distributed databases for OLTP workloads that require strong ACID guarantees at scale, this explains how we handle the hard parts differently. As already describedin a previous blog (https://regatta.dev/blog/regattas-architecture-a-birds-eye-view/), the entire functionality of RegattaDB (whether transactional or analytical) is always fully supported across nodes’ boundaries and regardless of how the data is distributed across the cluster. For example, the strong ACID guarantees are fully supported even when the transaction includes rows that reside on different nodes; Distributed JOINs are fully supported across node boundaries, etc. This is a fundamental design principle differentiating RegattaDB from the typical approach of “scale-out-by-sharding” databases. RegattaDB supports multiple isolation levels for OLTP/OLAP workloads – all treated as first-class citizens in our implementation. Those isolation levels include the strongestSerializablelevel (with external consistency), as well as the somewhat more relaxedRead CommittedandRepeatable Readlevels. All these isolation levels provide their full, no-compromise guarantees across the entire cluster. RegattaDB allows transactions to choose their isolation level on a transaction-by-transaction basis, and a concurrent mixture of isolation levels is fully and optimally supported. ## What is Serializable Isolation in a Distributed Database? Serializable isolation is the strongest isolation level defined by the SQL standard. It guarantees that concurrent transactions produce results identical to some serial (one-at-a-time) execution. In a single-node database this is hard difficult. In a distributed database with data spread across many nodes, achieving true serializability without gutting performance is one of the hardest unsolved problems in database engineering. ## RegattaDB: Serializable Isolation Level RegattaDB supports a trueSerializableisolation level. Without getting into formal details, serializability guarantees that the results of concurrently executing transactions will appear as if they executed one after the other (i.e., in an arbitrary serial order), without exposure to variousanomaliesthat are inherently an unavoidable part of the more relaxed isolation levels. > Terminology note:The termConcurrency Control Protocol(CCP) is used to describe the algorithmic approach and mechanisms used by a database to enforce a pertinent isolation level. ### Does Serializable Isolation Always Require a Performance Tradeoff? Strong transactional semantics in true scale-out databases are almost always perceived as requiring a significant performance compromise: - Distributed locking (often used by pessimistic CCPs) is meaningfully slower and more complicated than local, within-the-node, locks. As a result, its usage tends to cost in increased transaction latency and resource consumption. - Snapshots are used by some optimistic (and semi-optimistic) CCPs. Generally, in a true scale-out database, snapshots (often created for each transaction or even for each statement – depending on the exact isolation level) should each be perfectly consistent across the database nodes for the same point in time. Such high-rate, consistent, distributed snapshot creation is extremely challenging and tends not to scale well by the number of nodes and/or transaction numbers and rates – resulting in performance degradation. > Note:Some databases use clock-synchronization techniques to mitigate some of these challenges, as well as other CCP-related different challenges. Clock-synchronization techniques, and especially when not hardware-aided, are challenging to implement and often come with various performance-degradation aspects, such as the need to introduce delays in certain operations (e.g., in a read operation) and/or increasing the chances of transaction aborts (in the cases of optimistic locking techniques). - Optimistic CCPs’ main promise is to avoid a blocking coordination among transactions – i.e., by not using locks. Non-blocking operation is far from being a free lunch, as optimistic CCPs tend to cause transactions to “commit suicide” (abort) and re-run from scratch, on any data-access conflict with any other transactions. The “transaction suicide rate” in optimistic CCPs may become alarmingly high under some workloads. The “suicide rate” or abort-probability may rise even further when combining both short and lengthy transactions and queries. Furthermore, unfortunately, the increased complexities and uncertainties (e.g., about timing of events) in scale-out database configurations often cause the distributed variations of optimistic-locking CCPs to meaningfully (and sometimes even dramatically) increase the transaction aborts rate, effectively hurting the overall performance of the database. To sum up, strong transactional semantics in true scale-out databases are perceived as causing meaningful performance compromises due to (but not limited to)locks,snapshots,suicides-on-conflict, as well as some other elements. RegattaDB serializable isolation is using our proprietary, patented CCP that: - Does not use locks: In RegattaDB CCP, the main part of the transaction execution – the part when it does the “real work” – is done in a non-blocking manner, and hence without needing locks. In that respect, that part is completely optimistic. - Issnapshot-free: Transactions in RegattaDB serializable isolation level do not use snapshot, nor do they need clock-synchronization. - Unlike most optimistic protocols,doesn’t cause transactions to abort on detected conflicts(well, except of course for deadlock cases in which both optimistic and pessimistic protocols tend to abort a transaction per deadlock-cycle – more about this later). ### Autonomous Operation It is beyond the scope of this document to dive deeper into the execution model of transactions, queries, and statements in RegattaDB. However, it is worth mentioning that a statement execution is generally distributed and/or parallelized across the nodes containing the relevant data elements (as well as, under some circumstances, compute nodes that the statement decides to employ). In other words, it’snotthat there is “one node” that “truly executes the computation of a statement”, using all the rest of the nodes just as “storage nodes” from which it fetches the data. Instead, the transaction hasTransaction Agentsinstantiated on the nodes that are relevant for its execution. Those agents collaborate directly and, whenever required, may also exchange data (in a many-to-many fashion, thus avoiding single-node bottlenecks). For lengthier statements, such a data exchange facilitates a distributed pipelined execution. Needless to say, RegattaDB collaboration among the agents is as efficient and less-chatty as possible, opting each agent to operate as autonomously in its node as possible. Distributed algorithms are inherently harder to design than local algorithms. That fact is extra apparent with CCPs that are all about coordinating parallel distributed activities. Our philosophy in building the distributed aspects of the CCP algorithms and mechanisms was – similarly to the way transactions execute autonomously in RegattaDB (as described above) – to allow each of the transaction agents that operates in the cluster maximal autonomy. In RegattaDB, most of the CCP-related operations do not require tight coordination among the nodes. In fact, as discussed below, when the transaction is doing its “main work”, none of the CCP-related operations require coordination among the nodes. That general approach is great for performance but is also great for simplifying many of our internal algorithms and mechanisms… ### Conflict Resolution As mentioned, a transaction that executes in RegattaDB is completely non-blocking/optimistic during its “real work” part (hereafterWorking Phase). Unlike some optimistic CCPs, that transaction does not care about detecting any conflicts with other transactions (during the working phase). That results in a lightweight, almost invisible, concurrency-control overhead during the working phase of the transactions. It also means that deadlocks (among transactions) cannot happen during the working phase, and hence no deadlock-handling is required during that phase. If anybody would argue that transactions could run freely, completely ignoring conflicts for their entire lifetime, and serializability would magically “just happen”, they would probably be very wrong. Physics just won’t let that happen. As stated above, serializable CCP in RegattaDB doesn’t bother with conflicts during the working phase of the transaction. Once the CCP does deal with conflicts, that activity is done cheaply and mostly local (i.e., done by each of the transaction agents separately in their own relevant nodes), maintaining the “autonomous operation” style discussed above. I won’t get into all the details here, but I can say that there is a meaningful conflict tolerance built into the algorithms. For instance, the conflict handling is done in the fine-resolution of a single data-cell (rather than at the row-level or at the level of a block/page of rows), thus reducing “false conflicts”. In addition, we care only about one out of the three types of conflicts (W/R, R/W, W/W). Furthermore, there is a sophisticated (optimistic flavor of) “predicate locking” in place. And now for something else that sets our CCP apart: Unlike the typical optimistic protocols, in RegattaDB the detection of conflicts does not result in aborting the transaction. As already mentioned, there is only one (legitimate and unavoidable) exception. In case of a deadlock, everybody, the pessimistic CCPs, the optimistic CCPs, as well as RegattaDB CCP will have to abort a transaction… Deadlocks are covered in more detail next. ### How Do Distributed Databases Handle Deadlocks and Why Does It Matter? #### Deadlock Handling in General Deadlock handling is one of the most overlooked performance bottlenecks . When transactions access rows in conflicting orders, a deadlock cycle can form and how the database detects and resolves it has a major impact on throughput under load. Ideally, a deadlock should be detected reliably, and then resolved by killing one of the transactions participating in the deadlock. Deadlockdetectionis typically achieved by an algorithm that searches for directed cycles in a dynamic transaction dependency-graph. It is a somewhat expensive process, but is considered reasonably doable within the boundaries of a single node database, where the dependency-graph resides entirely in the local RAM of that single node. Enter distributed databases… The dynamic transaction dependency information is potentially spread across the entire cluster. Seeking for directed cycles of a dynamicdistributedgraph (with cross-transaction dependencies potentially occurring in different nodes) is not an easy task, nor is it particularly cheap… That challenge often leads distributed transactional databases to useDeadlockPreventioninstead of deadlock detection techniques. Deadlock prevention techniques are much more “easy going” with killing transactions. Instead of detecting actual deadlocks, deadlock prevention techniques would terminate transactions much more “brutally”, sometimes even when the only issue is that they are merely “waiting” for a resource that will soon become available, without any real deadlock occurring. Those prevention techniques indeed eliminate the creation of deadlocks, but with an amplified penalty of killing transactions that could have executed without causing a true deadlock. This, obviously, turns to effectively slow down transaction processing, sometimes just because there were some legitimate non-deadlocking conflicts or because there was more load causing more waits (which is a very bad constellation for killing a transaction and re-running its entire work, as it also makes the effective load even heavier…). #### RegattaDB Summarizing: - Unlike the typical optimistic protocols, conflict detection in RegattaDB does not result in aborting the transaction, with the legitimate and unavoidable exception of deadlocks. In case of a deadlock, everybody, the pessimistic CCPs, the optimistic CCPs, as well as the CCP will have to abort a transaction. - In RegattaDB, the transaction execution is completely non-blocking/optimistic during its working phase. Additionally, the transaction does not care about detecting any conflicts with other transactions during the working phase. That means that deadlocks cannot happen during the working phase, and hence no deadlock handling is required during that phase. - When the RegattaDB CCP deals with conflicts, that activity is executed cheaply and mostly local (i.e., done by each of the transaction agents separately inside its relevant node), maintaining the “autonomous operation” style. In RegattaDB CCP, the type of deadlock that is related to conflicts is more simplistic, and its detection is more lightweight than performing deadlock handling during the transaction working phase. In fact, the deadlock detection takes place when the transactions no longer hold their possibly-heavy resources required for their execution. Furthermore, and because of the above, the CCP takes the approach of distributed deadlockdetection(rather than deadlockprevention) that does not needlessly abort transactions without any real deadlock. ### Linearly-Scalable, Efficient Distributed Commitment RegattaDB was designed and developed from day one with truly large clusters in mind. RegattaDB’s CCP was designed and built to excel both with small clusters of a handful of nodes or even a single node, very-large clusters (e.g., 10,000 nodes), and anything in between. Designing a reliable and fault-tolerant atomic distributed commitment mechanism is challenging. Doing it in a linearly-scalable-performing fashion is even harder. Commitment mechanisms that work reasonably well in small clusters may behave less charmingly given a large cluster. A short, small, transaction that involves very few nodes (e.g., 3 nodes in a 500-node cluster) should be able to commit without involving many other nodes in the cluster, otherwise, linear-scalability would sooner or later be compromised. When committing a transaction, RegattaDB’s CCP will generally involve the nodes that specifically wrote / modified data for the committing transaction. It will not involve a larger forum (this is essential for efficiency and for linear scalability). The commitment is performed in the most lightweight manner possible. For various reasons, we preferred to create a variation of a two-phase commit rather than to use a mechanism that is based on a consensus algorithm. ### Row-Versions Talking about our (flash-optimized) persistent data layouts is beyond the scope of this document. It is worth mentioning, however, that it’s not a slotted-page structure, nor is it an LSM Tree. Instead, we developed our own log-structured data layout that operates very differently from LSM Tree, effectively realizing an MVCC data-layout that allows writing and reading variable-size rows in a performant manner with well-bounded low I/O amplification, thus making it optimal for a large variety of workload types. Interestingly, this layout also releases us from needing to maintain redo/undo logs. When all RegattaDB’s transactions are running in serializable isolation level, each row will tend to have a single row-version only. When a transaction TR100 modifies an existing row R10, then, for a very short period, we will have both the old (“current”) row-version and the new row-version (containing the modifications done by TR100). A short time after the commitment, the old row-version will be cleaned, very cheaply. In fact, the internal mechanics of this are very close to saying that the “row is overwritten by the new contents”, although a slightly better way of thinking about it is that the new row-versionreplacesthe old row-version. Row-versions are covered in more detail later in this document. ### Predicate Locking RegattaDB’s serializable CCP approach aims to permit as much concurrency as possible. For that purpose, among other things, RegattaDB’s CCP includes a sophisticated proprietary optimistic flavor of “predicate-locking” algorithms. Predicate Lockingis a topic that, despite the fact that it is rarely discussed, is arguably one of the big rocks in allowing the restrictive serializable isolation level to gain better concurrency. If transaction TR100 selects a (potentially small) number of rows to act upon (hereafterThe Selected Row-Set), by specifying a predicate, then, generally, it is desired (and in most cases essential) that other transactions (e.g., TR1) wouldn’t modify rows in a way that would alter the selected row-set (e.g., cause another row to satisfy TR100’s predicate without TR100’s being able to do anything about it as it already selected its rows) and commit before TR100 commits. Perfect enforcement, while still allowing as much concurrency as possible, is known to be a hard problem, and the typical solutions provided by relational databases are arguably very compromising. RegattaDB can utilize predicate-locking even on complex predicates whose evaluation may be distributed, and that may also combine indexed and non-indexed elements. RegattaDB’s predicate-locking algorithms go much further than just “let’s lock an index-page and thus block rows from illegally entering or leaving the population selected by the predicate”. This topic clearly deserves a blog of its own, but, in the meantime, here is an example that demonstrates what our technology can provide: Consider a fictitiousemployeestable that, among others, contains the columnsprofession, hair_color,andshoe_size(each may or may not be indexed). Suppose we have a transaction TR100 that would like to act upon all employees that are dentists whose hair color is red/orange/yellow and whose shoe size is in the range 6-8. Suppose, at the time TR100 searched for its selected row-set,Jameswas acarpenter, withbrownhair and a shoe size of 9. James is clearly outside of TR100’s selected row-set. Now let’s assume TR100 is still executing, and already chose its selected row-set. Let’s consider three short transactions, TR1, TR2 and TR3: - TR1 modifies James’ profession todentist. - TR2 modifies James’ hair color tored. - TR3 modifies James’ shoe size to 7. Assuming TR2 and TR3 do not execute at all, could TR1 execute (and commit) concurrently to TR100? The answer is “yes”. The fact that James becamedentistwouldn’t necessitate its inclusion in TR100’s selected row-set. > Note:Whether a typical relational database will allow those to run concurrently is a different question… RegattaDB’s technology does allow that concurrency. In fact, any single transaction out of those three (TR1 or TR2 or TR3) could in theory execute and commit concurrently to TR100 without violating the desired consistency expectations. Furthermore, any combination of two out of those three transactions (e.g., TR1 and TR2) could in theory execute and commit concurrently to TR100 without violating consistency. However, all the three transactions (TR1 and TR2 and TR3) cannot execute and commit concurrently to TR100, as their end results will make James qualified to be selected by TR100 (that unfortunately didn’t select him). Then, the anomaly that TR100 did not include James could easily lead to violation of serializability. RegattaDB technology can understand all that and allow just the right level of concurrency. Maybe just another small example, if James’ friend Jane is adentistwithredhair and shoe size7, a transaction TR4, modifying her hair color toorange, could execute and commit concurrently to TR100, as the inclusion of Jane in TR100’s selected row-set is agnostic to whether Jane’s hair color is red or orange. Here again, RegattaDB technology can allow that level of concurrency. Whether other databases could allow it is a different question. ## RegattaDBRead CommittedandRepeatable ReadIsolation Levels ### General Description In addition to theSerializableisolation level, RegattaDB supports (as first-class-citizens) theRead CommittedandRepeatable Readisolation levels (that are often also denoted as “snapshot isolation levels”). While those isolation levels are by-definition more relaxed than theSerializablelevel, they still fully provide their transactional guarantees in a non-compromised manner across the entire cluster, also for transactions that deal with multiple rows that reside in multiple nodes. To achieve that, RegattaDB uses proprietaryPoint-in-Time (PiT)technology that supports an extremely high rate of transactions (i.e. millions per second or even more) in very large clusters, pretty cheaply, without paying the penalty typically associated with the creation of consistent distributed snapshots, and without relying on clock-synchronization. Unlike the typical semi-optimistic approaches used by other database, where reading is done in a non-blocking manner and writing requires the usage of blocking locks, RegattaDB transaction’s working phase is completely non-blocking also under Read Committed and Repeatable Read isolation levels. In RegattaDB, many of the principles discussed above for the Serializable isolation level are applied in those snapshot isolation levels as well. It’s just that reading is done using the contents of a specific point-in-time, as those isolation levels define, and the conflict detection and resolution is more relaxed, thus complying with the defined semantics of those snapshot isolation levels. ### Row-Versions #### In General When those snapshot isolation levels are in use (either for OLTP or OLAP-like workloads), multiple row-versions may be created for some of the rows (that happened to be modified multiple times recently), as multiple transactions or statements may read the contents of those rows for multiple different points-in-time, where those recent modifications could result in different contents (=row-versions) for those different points-in-time. > Note:While this could generally lead to non-serializable transactional execution, such anomalies are par for the course for those MVCC isolation levels. Once a transaction that created a snapshot completes its work (e.g., the statement completed, or the transaction commits – again, depending on the exact isolation level), its snapshot is no longer needed. That means that some row-versions stored by the database may no longer be needed, and they can beCleaned(i.e., removed). Normally, the “most up-to-date” row-version survives (well, except for a case where a transaction TR1 took a snapshot, is reading row R10, and then a transaction TR100 removes the row and commits, while TR1 is still running – interestingly, R10 no longer exists, but a historical row-version of it is still maintained for the sake of TR1 – until TR1 completes its execution). In general, the cleaning of those historical row-versions is by no means trivial, as sometimes, a specific row-version “serves” multiple snapshots, so the discovery of which row-versions could be cleaned, and when, is often considered non-trivial. As a result of all the above, relational databases that support snapshot isolation levels need to maintain historical row-versions of the database, at least until the moment each of those could be cleaned. #### Different Implementations for Row-Versioning Different databases vary in the way they implement, store, and clean row-versions. For example, Oracle generally has one “main version” of the row stored on disk (in the main “table space”), and the rest of the row-versions are stored in the undo log (on disk). Note that the “new version” is first written to the redo log and only then moved to the main table space. PostgreSQL, as another example, stores each new row-version as a separate entry in its main data-layout. Each of those approaches have their advantages and disadvantages. For example, in Oracle, the undo log has a maximal size. If a lengthy transaction holds a snapshot for “too-long”, and it reads a row (from that snapshot) whose relevant row-version was already retired from the undo log (as it has a limited size), the transaction will simply fail… PostgreSQL, on the other hand, will generally not suffer from that problem, but it relies on the heavy VACUUM background process that crawls the database, seeking for row-versions that could be cleaned. That crawling is often criticised as undesired heavy resource consumption that hurts the overall performance, sometimes in a pretty unpredictable manner. #### The Penalty of Reading a Row that has Multiple Row-Versions The fact that databases store multiple historical row-versions of the same row requires the database to “know” which row-version a certain (reading) transaction needs. Many of those MVCC databases need to search for the “right” row-version of the row by scanning all its row-versions (and, for example, comparing their “timestamp” with the pertinent snapshot’s “timestamp” until reaching the “right” row-version for the read). With that often-used strategy, the existence of many different row-versions for the same row could hurt (or even meaningfully hurt) the row read performance, as the above search is often done by traversing the on-disk row-versions, using multiple disk I/Os. This is clearly one of the (quite many) reasons why “OLTP and OLAP don’t work well together”: When one executes multiple lengthy OLAP queries together with a decent OLTP workload, there are greater chances for a larger number of row-versions, at least for some of the rows (well – the “hotter” rows, which are accessed more frequently – which actually worsens the performance degradation…). #### RegattaDB In RegattaDB, and unlike the typical MVCC databases, a row read will not require the expensive on-disk traversal among all the row’s versions to determine the right row-version to read. Instead, the inherent metadata that is anyways (efficiently) accessed during a row read, provides all the information necessary to instantly laser-focus on the right row-version. In that respect, a workload containing a mixture of OLTP transactions and OLAP-like queries (that would typically use those snapshot isolation-levels) may create rows with multiple row-versions. In RegattaDB, statements that read such rows under snapshot isolation won’t pay an extra penalty. The same could be said for concurrent OLTP transactions that run in Serializable isolation. As for row-version cleaning: In RegattaDB, unlike Oracle’s approach mentioned-above, row-versions that are “needed” by existing transactions will not be retired. In that respect, RegattaDB is closer to the above-mentioned PostgreSQL approach. However, RegattaDB knows how to extremely efficiently pinpoint which row-versions could be cleaned, without needing to perform heavy operations, and without needing possibly-heavy acts such as the PostgreSQL VACUUM crawling. If you’re building systems that require strong ACID guarantees at scale, whether for OLTP, mixed OLTP/OLAP, or agentic AI workloads, RegattaDB’s concurrency-control architecture is designed to handle it without compromise. See how it performs under real workloads in ourTPC-C benchmark post (https://regatta.dev/blog/regattadb-tpc-c-benchmark-750k-tps-1-5m-warehouses/), or talk to our team atinfo@regatta.dev (mailto:info@regatta.dev)about your use case. --- # Connect Your Spring Boot Application to RegattaDB Source: https://regatta.dev/blog/connect-your-spring-boot-application-to-regatta Published: 2025-03-05 Updated: 2026-10-06 Author: Eyal Lotan Categories: Platform In this tutorial, we'll show you just how simple it is to deploy a Spring Boot application that interacts with RegattaDB using JDBC. By following a few steps, you'll have a working backend capable of handling customers and purchases with a powerful relational database. At RegattaDB, we believe in making database integration seamless for developers. Whether you're building a new application or migrating an existing one, connecting your Spring Boot backend to RegattaDB Database is quick and effortless. With support for JDBC and Hibernate (JPA), you can easily integrate RegattaDB into your application and start managing data efficiently. ## Set Up Your RegattaDB Deploying a RegattaDB is easy and can be done with just a click of a button. In this tutorial, we will use Regatta Cloud, our fully managed database solution. Regatta Cloud provides an elastic, scalable, and hassle-free way to deploy RegattaDB systems. You can also opt for an on-premises deployment to match your specific needs. - Log in to theRegatta Cloud (https://cloud.regatta.dev/) - Click on “CREATE NEW CLUSTER”: Image: cluster status - Choose a descriptive name and select the cluster type: Image: create new cluster - Click Confirm and wait for the cluster to start: Image: clusters menu - Once your cluster is deployed, click on its name in the Clusters menu to view its details, including connectivity information: Image: connectivity settings ### Install JDK Download and install a Java Development Kit. In this tutorial, we use Oracle JDK 17.0.10 LTS. ### Install Maven The example application used in this tutorial uses Maven to manage application dependencies. ### Get The Application Code ```bash git clone https://github.com/Regatta-Dev/spring-boot-app.git ``` ### Add Dependencies The RegattaDB Spring Boot app will be available under the spring-boot-app root directory. Your Spring Boot project requires theRegatta JDBC Driverto communicate with the database. Navigate to thejdbc_app directory, and add the following dependency to yourpom.xml file: ```xml dev.regatta regatta-jdbc 1.4.0 ``` Note: If you’re using Hibernate (JPA), also include the regatta-hibernate dependency. ### Configure Your Application Navigate tojdbc_app/src/main/resourcesand add the following configurations in yourapplication.propertiesfile to connect to your RegattaDB database: ```bash # Database Configuration spring.datasource.url=jdbc:regatta:: spring.datasource.username= spring.datasource.password= spring.datasource.driver-class-name=dev.regatta.jdbc1.Driver ``` ### Build and Run the Application Navigate to your project directory and build it using Maven: ```bash mvn clean install ``` Once the build is successful, start the application: ```bash mvn spring-boot:run ``` You should see the following output: ```bash . ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/ ___)| |_)| | | | | || (_| | ) ) ) ) ' |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot :: (v3.1.0) 2025-03-01T14:36:51.741+02:00 INFO 27868 --- [ main] dev.regatta.jdbc_springboot.App : Starting App using Java 17.0.10 with PID 27868 (/home/eyallotan/spring-boot-app/jdbc_app/target/classes started by eyallotan in /home/eyallotan/spring-boot-app/jdbc_app) 2025-03-01T14:36:51.743+02:00 INFO 27868 --- [ main] dev.regatta.jdbc_springboot.App : No active profile set, falling back to 1 default profile: "default" 2025-03-01T14:36:52.272+02:00 INFO 27868 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8080 (http) 2025-03-01T14:36:52.278+02:00 INFO 27868 --- [ main] o.apache.catalina.core.StandardService : Starting service [Tomcat] 2025-03-01T14:36:52.278+02:00 INFO 27868 --- [ main] o.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/10.1.8] 2025-03-01T14:36:52.350+02:00 INFO 27868 --- [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext 2025-03-01T14:36:52.351+02:00 INFO 27868 --- [ main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 578 ms 2025-03-01T14:36:52.592+02:00 INFO 27868 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080 (http) with context path "" 2025-03-01T14:36:52.596+02:00 INFO 27868 --- [ main] d.r.j.service.DatabaseSetupService : Starting table creation... 2025-03-01T14:36:52.599+02:00 INFO 27868 --- [ main] dev.regatta.jdbc1.RegConnection : Creating connection to the database with user admin and url 34.73.76.233:8850 2025-03-01T14:36:53.616+02:00 INFO 27868 --- [ main] dev.regatta.jdbc1.RegConnection : Database connection created 2025-03-01T14:36:53.766+02:00 INFO 27868 --- [ main] dev.regatta.jdbc1.RegResultSet : ResultSet closed 2025-03-01T14:36:53.766+02:00 INFO 27868 --- [ main] dev.regatta.jdbc1.RegStatement : Statement closed 2025-03-01T14:36:54.153+02:00 INFO 27868 --- [ main] dev.regatta.jdbc1.RegStatement : Statement closed 2025-03-01T14:36:54.988+02:00 INFO 27868 --- [ main] dev.regatta.jdbc1.RegConnection : Connection closed 2025-03-01T14:36:54.993+02:00 INFO 27868 --- [ main] dev.regatta.jdbc_springboot.App : Started App in 3.443 seconds (process running for 3.591) ``` Your Spring Boot app is now up and running, connected to RegattaDB! ### Application Details #### Controllers jdbc_app/src/main/java/dev/regatta/jdbc_springboot/controller/ CustomerController.javadefines the controller interface to the customers table: ```java package dev.regatta.jdbc_springboot.controller; import dev.regatta.jdbc_springboot.entity.Customer; import dev.regatta.jdbc_springboot.entity.Purchase; import dev.regatta.jdbc_springboot.service.CustomerService; import dev.regatta.jdbc_springboot.service.PurchaseService; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.*; import com.github.javafaker.Faker; import java.math.BigDecimal; import java.time.LocalDate; import java.util.ArrayList; import java.util.List; import java.util.Random; @RestController @RequestMapping("/customers") public class CustomerController { @Autowired private CustomerService customerService; @Autowired private PurchaseService purchaseService; @GetMapping public List getAllCustomers() { return customerService.findAll(); } @GetMapping("/{id}") public Customer getCustomerById(@PathVariable Long id) { return customerService.findOne(id); } @PostMapping public Customer createCustomer(@RequestBody Customer customer) { return customerService.create(customer); } @PutMapping("/{id}") public Customer updateCustomer(@PathVariable Long id, @RequestBody Customer customer) { return customerService.update(id, customer); } @DeleteMapping("/{id}") public ResponseEntity deleteCustomer(@PathVariable Long id) { boolean isDeleted = customerService.deleteCustomerById(id); if (isDeleted) { String message = "Customer with ID " + id + " deleted successfully."; return ResponseEntity.ok(message); } else { String errorMessage = "Customer with ID " + id + " not found."; return ResponseEntity.status(404).body(errorMessage); } } /** * Endpoint to populate the database with 1000 customers for testing. * Each customer will have between 1 to 5 purchases. * URL: POST /customers/populate */ @PostMapping("/populate") public String populateCustomersAndPurchases() { try { int numberOfCustomers = 1000; int bulkSize = 100; int batches = numberOfCustomers / bulkSize; int remaining = numberOfCustomers % bulkSize; long customerIdCounter = 1L; long purchaseIdCounter = 1L; Faker faker = new Faker(); Random random = new Random(); List allPurchases = new ArrayList<>(); // Generate and collect customers and their purchases in batches for (int b = 0; b < batches; b++) { List customers = generateCustomersWithPurchases( bulkSize, faker, random, customerIdCounter, purchaseIdCounter); // Perform bulk insertion for customers customerService.createAll(customers); for (Customer customer: customers) { allPurchases.addAll(customer.getPurchases()); } // Perform bulk insertion for purchases purchaseService.createAll(allPurchases); allPurchases.clear(); customerIdCounter += bulkSize; purchaseIdCounter += customers.stream().mapToInt(c -> c.getPurchases().size()).sum(); } // Handle remaining customers if (remaining > 0) { List customers = generateCustomersWithPurchases( remaining, faker, random, customerIdCounter, purchaseIdCounter); for (Customer customer : customers) { allPurchases.addAll(customer.getPurchases()); } // Perform bulk insertion for customers customerService.createAll(customers); // Perform bulk insertion for purchases purchaseService.createAll(allPurchases); } return numberOfCustomers + " customers with purchases have been successfully added to the database."; } catch (Exception e) { return "An error occurred during the population process: " + e.getMessage(); } } /** * Generates a list of customers with random data and purchases. * * @param count the number of customers to generate * @param faker the Faker instance for generating data * @param random the Random instance for generating random numbers * @param customerIdStart the starting customer ID * @param purchaseIdStart the starting purchase ID * @return a list of generated customers */ private List generateCustomersWithPurchases(int count, Faker faker, Random random, long customerIdStart, long purchaseIdStart) { List customers = new ArrayList<>(count); for (int i = 0; i < count; i++) { Customer customer = new Customer(); customer.setCustomerId(customerIdStart++); String rawName = faker.name().fullName(); String sanitizedName = rawName.replace("'", ""); customer.setName(sanitizedName); customer.setEmail(faker.internet().emailAddress()); String phone = faker.phoneNumber().phoneNumber(); customer.setPhone(phone.length() > 12 ? phone.substring(0, 12) : phone); // Generate between 1 to 5 purchases for this customer int numberOfPurchases = random.nextInt(5) + 1; for (int p = 0; p < numberOfPurchases; p++) { Purchase purchase = new Purchase(); purchase.setPurchaseId(purchaseIdStart++); // Random purchase date within the last 2 years LocalDate purchaseDate = LocalDate.now().minusDays(random.nextInt(730)); purchase.setPurchaseDate(purchaseDate); // Random price between $10 and $1000 with 2 decimal places BigDecimal price = BigDecimal.valueOf(faker.number().randomDouble(2, 10, 1000)); purchase.setPrice(price); purchase.setItem(faker.commerce().productName()); purchase.setCustomer(customer); customer.getPurchases().add(purchase); } customers.add(customer); } return customers; } } ``` Note: The populate endpoint can be used to create 1,000 random customers. Each customer will be randomly assigned 1 to 5 purchases. Similarly, thePurchaseController.javadefines the controller interface to thepurchasestable. #### Services jdbc_app/src/main/java/dev/regatta/jdbc_springboot/service/DatabaseSetupService.javadefines the main service that creates the database tables: ```java package dev.regatta.jdbc_springboot.service; import java.sql.*; import java.util.HashSet; import java.util.Set; import org.springframework.beans.factory.annotation.Value; import org.springframework.context.event.ContextRefreshedEvent; import org.springframework.context.event.EventListener; import org.springframework.stereotype.Service; import org.slf4j.Logger; import org.slf4j.LoggerFactory; @Service public class DatabaseSetupService { private static final Logger logger = LoggerFactory.getLogger(DatabaseSetupService.class); @Value("${spring.datasource.url}") private String jdbcURL; @Value("${spring.datasource.username}") private String jdbcUsername; @Value("${spring.datasource.password}") private String jdbcPassword; @EventListener(ContextRefreshedEvent.class) public void createTables() { logger.info("Starting table creation..."); try (Connection connection = DriverManager.getConnection(jdbcURL, jdbcUsername, jdbcPassword); Statement statement = connection.createStatement()) { Set existingTables = getExistingTables(connection); if (!existingTables.contains("customers")) { createCustomerTable(statement); } else { logger.info("Customer table already exists."); } if (!existingTables.contains("purchases")) { createPurchaseTable(statement); } else { logger.info("Purchase table already exists."); } } catch (SQLException e) { logger.error("Failed to check or create tables in the database.", e); throw new RuntimeException("Failed to check or create tables in the database.", e); } } private Set getExistingTables(Connection connection) throws SQLException { Set tables = new HashSet<>(); String showTablesSQL = "SHOW TABLES"; try (Statement statement = connection.createStatement(); ResultSet resultSet = statement.executeQuery(showTablesSQL)) { while (resultSet.next()) { tables.add(resultSet.getString(1).toLowerCase()); } } logger.debug("Existing tables: {}", tables); return tables; } private void createCustomerTable(Statement statement) throws SQLException { String createCustomerTableSQL = """ CREATE TABLE customers ( customerid BIGINT PRIMARY KEY INDEX, name VARCHAR(100) NOT NULL, email VARCHAR(100) NOT NULL, phone VARCHAR(15) ); """; statement.execute(createCustomerTableSQL); logger.debug("Customer table created or already exists."); } private void createPurchaseTable(Statement statement) throws SQLException { String createPurchaseTableSQL = """ CREATE TABLE purchases ( purchaseid BIGINT PRIMARY KEY INDEX, customerid BIGINT NOT NULL REFERENCES customers INDEX, item VARCHAR(255), price DECIMAL(10, 2), purchasedate DATE ); """; statement.execute(createPurchaseTableSQL); logger.debug("Purchase table created or already exists."); } } ``` CustomerService.javaimplements theCustomerService, which allows you to perform CRUD operations on customers. This service uses the Customer entity that is defined inentity/Customer.java: ```java package dev.regatta.jdbc_springboot.entity; import java.util.ArrayList; import java.util.List; public class Customer { private Long customerId; private String name; private String email; private String phone; private List purchases = new ArrayList<>(); public Customer() { } public Customer(Long customerId, String name, String email, String phone) { this.customerId = customerId; this.name = name; this.email = email; this.phone = phone; } // Getters and Setters public Long getCustomerId() { return customerId; } public void setCustomerId(Long customerId) { this.customerId = customerId; } public String getName() { return name; } public void setName(String name) { this.name = name; } public String getEmail() { return email; } public void setEmail(String email) { this.email = email; } public String getPhone() { return phone; } public void setPhone(String phone) { this.phone = phone; } public List getPurchases() { return purchases; } public void setPurchases(List purchases) { this.purchases = purchases; } @Override public String toString() { return "Customer{" + "customerId=" + customerId + ", name='" + name + '\'' + ", email='" + email + '\'' + ", phone='" + phone + '\'' + '}'; } } Instances of the Purchase class, defined in jdbc_app/src/main/java/dev/regatta/jdbc_springboot/entity/Purchase.java, represent rows in the purchases table: package dev.regatta.jdbc_springboot.entity; import java.math.BigDecimal; import java.time.LocalDate; public class Purchase { private Long purchaseId; private Long customerId; private String item; private BigDecimal price; private LocalDate purchaseDate; // Getters and Setters public Long getPurchaseId() { return purchaseId; } public void setPurchaseId(Long purchaseId) { this.purchaseId = purchaseId; } public Long getCustomerId() { return customerId; } public void setCustomerId(Long customerId) { this.customerId = customerId; } public String getItem() { return item; } public void setItem(String item) { this.item = item; } public BigDecimal getPrice() { return price; } public void setPrice(BigDecimal price) { this.price = price; } public LocalDate getPurchaseDate() { return purchaseDate; } public void setPurchaseDate(LocalDate purchaseDate) { this.purchaseDate = purchaseDate; } public void setCustomer(Customer customer) { if (customer != null) { this.customerId = customer.getCustomerId(); } else { this.customerId = null; } } } ``` Similarly, thePurchasesService.javaimplements thePurchasesService, which allows you to perform CRUD operations on purchases. This service uses thePurchaseentity that is defined inentity/Purchase.java. #### Entities Instances of the Customer class, defined injdbc_app/src/main/java/dev/regatta/jdbc_springboot/entity/Customer.java, represent rows in thecustomerstable: ```java package dev.regatta.jdbc_springboot.entity; import java.util.ArrayList; import java.util.List; public class Customer { private Long customerId; private String name; private String email; private String phone; private List purchases = new ArrayList<>(); public Customer() { } public Customer(Long customerId, String name, String email, String phone) { this.customerId = customerId; this.name = name; this.email = email; this.phone = phone; } // Getters and Setters public Long getCustomerId() { return customerId; } public void setCustomerId(Long customerId) { this.customerId = customerId; } public String getName() { return name; } public void setName(String name) { this.name = name; } public String getEmail() { return email; } public void setEmail(String email) { this.email = email; } public String getPhone() { return phone; } public void setPhone(String phone) { this.phone = phone; } public List getPurchases() { return purchases; } public void setPurchases(List purchases) { this.purchases = purchases; } @Override public String toString() { return "Customer{" + "customerId=" + customerId + ", name='" + name + '\'' + ", email='" + email + '\'' + ", phone='" + phone + '\'' + '}'; } } ``` Instances of thePurchaseclass, defined injdbc_app/src/main/java/dev/regatta/jdbc_springboot/entity/Purchase.java, represent rows in thepurchasestable: ```java package dev.regatta.jdbc_springboot.entity; import java.util.ArrayList; import java.util.List; public class Customer { private Long customerId; private String name; private String email; private String phone; private List purchases = new ArrayList<>(); public Customer() { } public Customer(Long customerId, String name, String email, String phone) { this.customerId = customerId; this.name = name; this.email = email; this.phone = phone; } // Getters and Setters public Long getCustomerId() { return customerId; } public void setCustomerId(Long customerId) { this.customerId = customerId; } public String getName() { return name; } public void setName(String name) { this.name = name; } public String getEmail() { return email; } public void setEmail(String email) { this.email = email; } public String getPhone() { return phone; } public void setPhone(String phone) { this.phone = phone; } public List getPurchases() { return purchases; } public void setPurchases(List purchases) { this.purchases = purchases; } @Override public String toString() { return "Customer{" + "customerId=" + customerId + ", name='" + name + '\'' + ", email='" + email + '\'' + ", phone='" + phone + '\'' + '}'; } } ``` ### Testing API Endpoints Populate Customers and Purchases ```java [16:06:24] eyallotan | (main) | ~/spring-boot-app/jdbc_app$ curl -X POST http://localhost:8080/customers/populate 1000 customers with purchases have been successfully added to the database. ``` Retrieve a Customer by ID ```java [16:49:12] eyallotan | (main) | ~/spring-boot-app/jdbc_app$ curl -s -X GET http://localhost:8080/customers/17 | jq { "customerId": 17, "name": "Sean Fadel", "email": "nathanial.kerluke@hotmail.com", "phone": "1-727-196-44", "purchases": [ { "purchaseId": 55, "customerId": 17, "item": "Heavy Duty Leather Computer", "price": 605.14, "purchaseDate": "2025-02-04" }, { "purchaseId": 56, "customerId": 17, "item": "Awesome Leather Keyboard", "price": 794.91, "purchaseDate": "2025-01-13" }, { "purchaseId": 57, "customerId": 17, "item": "Sleek Bronze Watch", "price": 808.29, "purchaseDate": "2024-09-17" }, { "purchaseId": 58, "customerId": 17, "item": "Intelligent Rubber Gloves", "price": 647.99, "purchaseDate": "2024-09-16" }, { "purchaseId": 59, "customerId": 17, "item": "Awesome Marble Table", "price": 421.06, "purchaseDate": "2024-09-07" } ] } ``` Create a New Customer ```bash [16:57:22] eyallotan | (main) | ~/spring-boot-app/jdbc_app$ curl -s -X POST http://localhost:8080/customers \ > -H "Content-Type: application/json" \ > -d '{ > "customerId": 2100000, > "name": "John Doe", > "email": "john.doe@example.com", > "phone": "123-456-7890" > }' | jq { "customerId": 2100000, "name": "John Doe", "email": "john.doe@example.com", "phone": "123-456-7890", "purchases": [] } ``` Update a Customer ```bash [16:58:55] eyallotan | (main) | ~/spring-boot-app/jdbc_app$ curl -s -X PUT http://localhost:8080/customers/2100000 \ > -H "Content-Type: application/json" \ > -d '{ > "name": "Martin Doe", > "email": "martin.doe@example.com", > "phone": "098-765-4321" > }' | jq { "customerId": 2100000, "name": "Martin Doe", "email": "martin.doe@example.com", "phone": "098-765-4321", "purchases": [] } ``` Delete a Customer ```bash [16:59:42] eyallotan | (main) | ~/spring-boot-app/jdbc_app$ curl -s -X DELETE http://localhost:8080/customers/2100000 Customer with ID 2100000 deleted successfully. [17:01:28] eyallotan | (main) | ~/spring-boot-app/jdbc_app$ curl -X GET http://localhost:8080/customers/2100000 [17:01:36] eyallotan | (main) | ~/spring-boot-app/jdbc_app$ ``` For more details and full source code, check out the GitHub repository:Regatta Spring Boot Example (https://github.com/RegattaData/spring-boot-app). Happy coding! --- # RegattaDB’s Architecture: A Bird’s Eye View Source: https://regatta.dev/blog/regatta-s-architecture-a-bird-s-eye-view Published: 2024-12-24 Updated: 2026-10-06 Author: Erez Webman Categories: Platform, Technology In this blog I will provide a high level overview of RegattaDB’s design and architectural principles. While I keep this introduction still relatively high-level, in the next few blogs we will get into more details of various topics that I am covering here. We designed RegattaDB such that its core architecture and implementation will be agnostic to its deployment type. That is, RegattaDB’s core database is essentially the same regardless of whether you install it on physical (or virtual) servers in your on-prem, your cloud of choice, or whether you consume it as a service. ## Scale-Out, Mostly Shared-Nothing RegattaDB is mainly a scale-out shared-nothing clustered architecture where heterogeneous nodes (servers, VM’s, containers, etc.) cooperate and can perform lengthy (as well as short) SQL statements in a parallel/distributed manner, with many-to-many data propagation among the cluster nodes (i.e., intermediate data doesn’t need to pass via a central point). In a “shared-nothing” architecture, the disks are typically locally attached to the nodes. Even if they don’t, the guiding principle is that each disk is accessible only by a single node in the cluster. Unlike some scale-out architectures that embrace symmetrical homogeneous nodes, a RegattaDB cluster can consist of nodes of various sizes and configurations. The native mode is where there is no distinction between storage nodes and compute nodes and all nodes can do both data access and statement processing. Furthermore, compute-only and storage-only nodes can be added to the cluster – seamlessly supporting a “decoupled storage and compute” two-layer topology that may include “diskless” nodes and nodes with disks in the same cluster. ## Relational Data Model RegattaDB is a relational database, fully supporting the power of the relational model and everything else that should be expected from a comprehensive relational database, whether transactional or analytical. The architecture supports extension of the model for storing and processing semi-structured as well as unstructured data. ## Cluster-Wide Functionality RegattaDB’s entire functionality (whether transactional or analytical) is always fully supported regardless of how the data is distributed across the cluster – e.g., the strong ACID guarantees are fully supported even if the transaction includes rows that reside on different nodes; distributed JOINs are fully supported across node boundaries, etc. This is a fundamental design principle differentiating RegattaDB from the typical approach of “scale-out-by-sharding” databases. ## Very Large Clusters from Day One RegattaDB was designed and developed with truly large clusters in mind from day one. Regatta’s team has decades of in-depth experience building large scale, mission-critical, and high-performance data management and storage software systems. While RegattaDB can scale to thousands of nodes in a cluster, its scale-out design does not compromise performance or performance-efficiency of small configurations – even not of single node configurations. ## Concurrency-Control Protocol (CCP) For transactional processing, RegattaDB supports a fully serializable (and externally consistent) isolation level based on RegattaDB’s proprietary Concurrency Control Protocol (CCP). RegattaDB’s CCP is mainly optimistic, although unlike most optimistic protocols, it doesn’t cause transactions to abort on detected conflicts (well, except of course for deadlock cases in which both optimistic and pessimistic protocols tend to abort a transaction per deadlock-cycle). In general, RegattaDB’s CCP is snapshot-free and does not require clock synchronization. As already mentioned, the CCP provides the very same transactional guarantees, regardless of whether the data is distributed across the nodes or not. Furthermore, the CCP was built with scale-out in mind, and is fully optimized for large scale-out configurations. In addition to the strong serializable mode, RegattaDB also supports more relaxed isolation levels such asRepeatable ReadandRead Committed. Those relaxed isolation levels are also fully optimized for scale-out configurations. As described later on, read-only queries do not block writing transactions. RegattaDB’s CCP approach aims to permit as much concurrency as possible. For that purpose, among other things, RegattaDB’s CCP includes sophisticated “predicate-locking” algorithms (well, our own proprietary optimistic flavor of “predicate-locking”). RegattaDB can utilize predicate-locking even on complex predicates whose evaluation may be distributed, and that may also combine indexed and non-indexed elements. RegattaDB’s predicate-locking algorithms go much further than just “let’s lock an index-page and thus block rows from illegally entering or leaving the population selected by the predicate”. ## Transaction Commitment Transaction commitment in RegattaDB is a linearly-scalable mechanism that involves the nodes that specifically wrote data for the committing transaction rather than a much broader set of nodes. That property is obviously very important for linearly scalable performance of short transactions (that tend to involve a small number of nodes each) in very large clusters. ## Deadlock Detection Whenever deadlocks among transactions occur (which, by the way, can never happen during the main parts of RegattaDB’s transaction execution), we use distributed deadlockdetectiontechniques rather than deadlockpreventiontechniques, without hurting the performance-at-scale of the system. Note that deadlockpreventiontechniques (which are often used by distributed databases) may cause unneeded aborts due to false-positive detections. ## Up-to-the-Second Queries of Changing Data Consistent/serializable read-only queries, short or lengthy, can be performed on real-time up-to-the-second transactional data without blocking writing transactions from progressing. RegattaDB achieves this without the penalties, non-linearities, and global quiesce that are typically associated with distributed snapshot creations, as well as without the penalties and difficulties associated with clock synchronization techniques. The mechanisms are optimal for both high-rate short queries and lengthier queries. All of this applies to RegattaDB in both small and very large clusters. RegattaDB uses a persistent data layout that supports multi-versioning. As such, at any given moment, a row may have multiple versions associated with it. Unlike some databases that use MVCC, locating and reading the relevant version of a row does not require traversing the row’s versions themselves, and therefore does not create read I/O amplification in case a row happens to have a larger number of versions. ## Query Planning, Optimizers, Parallel & Distributed Computation RegattaDB’s query planner as well as static and dynamic optimizers are built from scratch with distributed configurations in mind. In other words, RegattaDB’s query planning and optimization were not first designed for a single node and then later expanded for distributed configurations as an afterthought. Whenever appropriate, lengthy computations are performed in a massively parallel and distributed manner across a potentially large number of nodes. These nodes cooperate and exchange intermediate results in a many-to-many fashion, thus avoiding potential single-node bottlenecks that could occur if such data were routed via a single node. RegattaDB can perform the most demanding and complex distributed JOINs, as well as other challenging computations such as distributed GROUP BY, distributed SORT, and so forth. ## Modular (On-Disk) Data Layout Architecture RegattaDB’s architecture is built with the understanding that different data and/or data-access styles may benefit from different (on-disk) data layouts. Therefore, while RegattaDB today supports a certain row store layout, it is already designed for future additions of other types of row stores, as well as column store, blob store, etc. To optimize I/O performance, RegattaDB implements its own data layouts directly on top of raw block storage, and does not need any underlying filesystem. ## Flash-optimized Data-Layouts, No Slotted-Pages, No Log-Structured Merge Tree RegattaDB’s first row store data layout type is specifically optimized for flash media. It allows us to optimally support both traditional small-rows-with-more-or-less-fixed-size, and variable-sized-large-rows-with-a-large-dynamic-range-of-sizes (within the same table). Since traditional slotted pages were not an ideal fit for that purpose, and since some properties of log-structured merge-trees may not always align well with flash media or certain types of workloads, we developed our own log-structured data layout that operates very differently from LSM tree. RegattaDB’s data-layout is optimal for a large variety of workload types. Additionally, RegattaDB’s B+Trees (that are used, for example, for indexes) massively leverage the high read-concurrency of flash media, allowing meaningfully faster and more efficient B+Tree accesses than algorithms that would assume more “generic” underlying storage (i.e., magnetic HDD). ## Extensive Read and Write-Back Caching RegattaDB uses in-RAM read and write-back caching. Sophisticated write-back caching techniques (both volatile and non-volatile) optimize transaction execution as well as support advanced processing, resulting in meaningful amortized disk I/O reduction for both log-based and B+Tree persistent structures – without hurting strict durability guarantees. Needless to say, RegattaDB ensures that the data is hardened to disk before a transaction commitment is acknowledged to the client. For read caching, we took an approach that we call “logical caching”. Many databases cache disk pages in RAM, which may be wasteful. For example, if a hot 100-byte row resides in an 8KB disk page that otherwise contains cold data, caching the entire page in RAM can lead to a “waste” of ~7.9KB of RAM, dramatically reducing the effectiveness of the read-cache. In RegattaDB, the hot row will be stored in RAM without needing to store the entire surrounding page content in RAM. Maintaining CPU-efficiency and RAM-allocation-efficiency with a logical cache has many fascinating challenges that I’ll cover in a separate blog. ## Data Distribution and Elasticity Data is distributed by an automatic algorithm that complies with user-defined constraints. With that approach, the user can decide how much control they assume and what degrees of freedom they leave to RegattaDB. In one extreme, RegattaDB can balance the data completely autonomously and transparently, and in the other extreme, the user can take full control and decide by themselves how to distribute the data. And, of course, any in-between combination can apply… RegattaDB’s architecture supports the ability to non-disruptively, under-the-hood, migrate data among nodes for the sake of balancing, etc., while transactions, short or lengthy, are executing. ## Distributed Primary and Secondary Indexes RegattaDB fully supports primary as well as secondary indexes, where the indexes can be massively distributed, if needed. By design, the distribution of an index across nodes does not have to be aligned with the distribution of the corresponding rows’ data across nodes, allowing the best performant usage of the indexes. --- # Sharding - some dirty little secrets Source: https://regatta.dev/blog/sharding-some-dirty-little-secrets Published: 2024-10-22 Updated: 2026-10-06 Author: Boaz Palgi Categories: Platform, Technology Image: His-face-is-partially-shadowe-1 A few years ago, Erez Webman and I wrote a white paper describing the dirty little secrets of scale-out sharding. Scale-out sharding as a technique to try to cope with the limitations of single-node writer database systems is in wide use, although it has many problematic issues. In this blog, I will offer a summary of the issues that we covered in that whitepaper, and encourage you to read the full whitepaper for a more comprehensive treatise. ## Who needs scale-out sharding anyway? Large data sets or high throughput applications challenge any single-node database. Large capacity exceeds the server’s storage. Heavy workloads exhaust CPU capacity, I/O resources, or memory (RAM). Upgrading servers with more storage, memory, and faster CPU might solve this challenge. However, this is expensive, and there is a limit to the capacity or workload that a single server can handle. The contemporary solution is often scale-out sharding. Large data sets or high throughput applications challenge any single-node database. Large capacity exceeds the server’s storage. Heavy workloads exhaust CPU capacity, I/O resources, or memory (RAM). Upgrading servers with more storage, memory, and faster CPU might solve this challenge. However, this is expensive, and there is a limit to the capacity or workload that a single server can handle. The contemporary solution is often scale-out sharding. With scale-out sharding, data is divided across multiple servers (“shards”) in a cluster according to a sharding criterion. Each server operates as an independent database that can easily handle its part of the total data. However, scale-out sharding requires the application code to be well-aware of the exact data placement across the local independent database servers (shards) such that it will be able to manage the workload across those shards. Sharding breaks developers’ expectations around serializability, externalizable behaviors and overall ACID system attributes. If you are building an application, you do not want to be in the business of designing and developing concurrency control and durability yourself. Having to implement ACID and other data integrity guarantees in the application code will slurp up a significant amount of development and financial resources. Attempts to maintain ACID-like guarantees at the application layer are known to be hard or even impossible, and in any case complex, painful, and usually buggy. Even experienced developers agree that it is much easier to rely on the database than to attempt to achieve ACID at the application level. Contrary to what is sometimes popular belief, scale-out sharding configurations typically do not offer the notion of a large, single, database. Scale-out sharding does not try to align many nodes to act like one big database. Rather, each node operates as an independent sub-database. As a result, some basic database functionality that can be expected from a single node database cannot be achieved in multi-node sharded databases. For example, cross-shard-boundaries transactions and analytics operations may not work, or not work well. In addition, sharded databases may suffer other issues including, for example, per-node performance bottlenecks, inefficient workload execution, and even volume-skews surpassing nodes’ available capacity. Changing sharded database cluster configurations, like adding or removing servers, is generally challenging, and requires significant modifications that developers inherently must make in the application code. In theDirty Little Secrets of Scale-out Sharding whitepaper (https://regatta.dev/resources/whitepapers/dirty-secrets-of-sharding-whitepaper), Erez and I dive deeper into these, and various related, topics: ### 1. Sharded databases cannot guarantee distributed ACID If data accuracy of database operations is important, then the database should guarantee ACID. Some developers might believe that it surely is possible to build applications on modern databases that do not guarantee ACID — writing code and logic that somehow guarantees correctness and ordering of operations at the application level. Of course, this is not necessarily possible, and inevitably introduces tradeoffs and complexity in the process and the application logic. This is known to be hard or even impossible, and in any case complex, painful, and usually buggy. Why are multi-nodes databases challenged to guarantee strong ACID? - Consider what happens when a distributed transaction was only able to commit “partially”, i.e. one local transaction (TR1) on Shard-1 commits successfully, while another local transaction (TR2) on Shard-2 fails to commit. In the whitepaper, Erez and I examine how this partial commit of the distributed transaction causes a window of inconsistency that remains open until the application can resolve the scenario that caused it. We will also review approaches that the application logic can choose that have a good chance of succeeding and thus to close the window of inconsistency. However, as you will see, there are cases where categorically none of those strategies can succeed, causing the inconsistent state to remain stuck forever. - Consistency issues can occur even if both local transactions commit successfully. In the whitepaper, Erez and I walk through a scenario where both local transactions, on both local shards, commit successfully. We will illustrate how even when both local transactions committed successfully, there was still no way to guarantee that both committed at the same time exactly. Hence data written by the first local transaction could have been visible after the first local transaction successfully committed and before the second local transaction committed. This breaks the atomicity. No atomicity means no ACID. This can in turn lead to further data inconsistencies in the database, lead to bugs in the reader’s code, and to crashing of the application. ### 2. Sharded databases are not well-suited for executing queries In this section of the whitepaper Erez and I analyze several examples of the impact of executing queries on scale-out sharding distributed databases. We review why application developers need to do a lot of hard work and to write a lot of complex and error-prone code in the application to attempt to realize the execution of queries. We also illustrate why in many cases writing code for the execution of such queries at the application level is simply not possible at all. RegattaDB frees developers from the burden of dealing with the underlying data infrastructure challenges, and allows developers to focus for 100% on the business logic. You can download the whitepaperhere (https://regatta.dev/resources/whitepapers/dirty-secrets-of-sharding-whitepaper). --- # RegattaDB: Simple beats complex – more detail Source: https://regatta.dev/blog/simple-beats-complex-more-detail Published: 2023-10-26 Updated: 2026-10-06 Author: Chad Sakac Categories: Platform While feature-rich, scale-out products may sound complex to manage, when designed right and with architectural simplicity at the core - the opposite is true. Simplicity in platforms translates to simpler and better code which in turn accelerates iteration velocity for devs. This post will analyze this topic in more detail, and discuss how RegattaDB does this. RegattaDB is very easy to use. With RegattaDB, users are guaranteed a powerful yet simple experience. Most of all as RegattaDB matures it represents one of the most simplifying opportunities for the broader data platform complexity that frustrates us all. RegattaDB offers the strongest-possible ACID guarantees, powered by groundbreaking technology that allows distributed transactions at high performance. Such ACID guarantees allow the application developer to focus on business logic, rather than trying to deal with various failure scenarios, race conditions and various other corner cases that are typical for databases that provide no or limited ACID guarantees. Developers working with RegattaDB write less code, and have shorter times-to-market, than those relying on NoSQL databases that are eventually-consistent, or on scale-out sharding databases that do not guarantee ACID across the entire cluster. Read more about RegattaDB’s transactional support here. RegattaDB guarantees strong ACID across the entire cluster, enabling transactions to safely span multiple nodes. Unlike traditional scale-out-by-sharding databases that have no or limited functionality across the boundaries of a single shard, all of RegattaDB’s functionality, whether transactional or analytical, is always fully supported across the entire cluster. This simplifies development as attempting to solve those scale-out-by-sharding limitations requires developers to write much more, and more complex application code. Importantly, in many cases, it is impossible to handle those limitations at the level of the application code, no matter how hard one tries. Traditional scale-out-by-sharding databases bring additional complexities and headaches to both developers and operations engineers. Due to the various limitations with scale-out sharding, the choice of sharding criterion is often critical. Unfortunately, no matter how hard one tries, any choice of sharding criterion will generally benefit one type of usage and hurt another. The way in which the application code is written is directly impacted by the choice of the sharding criterion. Sooner or later that sharding criterion may need to be modified (aka resharding), for instance to expand the cluster or to deal with capacity-overflow of a specific shard. Resharding is known to be a painful disruptive process. It involves massive reshuffling of data across single-node database shards and often requires significant changes to be written in the application code. In contrast, RegattaDB does not suffer from any of the above. The developer does not need to deal with any sharding criteria, as RegattaDB can automatically distribute tables across the cluster. Any excessive uneven growth or shrinkage in table rows stored across the intended disks and nodes will invoke automatic non-disruptive rebalancing, and so will any addition (or removal) of nodes or disks to a pool on which table data is stored. RegattaDB’s rebalancing does not require any modifications to the application code since the data placement is transparent to the application to begin with. This completely releases administrators from the operational headache and cost traditionally associated with resharding. Moreover, RegattaDB’s elasticity eliminates the need for careful “capacity planning” ahead of time. Rather than having to “commit” to a fixed configuration, you can start with your “best guess”, and if needed fine-tune later. Read more about RegattaDB’s elasticity here. RegattaDB’s sophisticated partitioning provides various benefits. First, it enables maintaining of locality among related rows. In addition, it allows tiering. Furthermore, it supports segregation for multi-tenancy purposes. Segregation also benefits some scenarios with multiple competing workloads. Partitioning is purely optional in RegattaDB. RegattaDB enables users to define partitioning with simple and intuitive partitioning-criteria, high-level policies and placement rules, leaving RegattaDB to do the underlying hard work. Unlike some other databases, RegattaDB takes as much responsibility as possible. For example, node capacity overflow would be automatically dealt with, way ahead of time, by automatic rebalancing. Read more about RegattaDB’s partitioning and tiering here. RegattaDB provides a single solution that delivers functionality that traditionally requires multiple separate types of databases, cumbersome ETL processes, and data warehouses; and requires to keep various types of data separated as “silos”. This traditional approach often results in operational complexities and inefficiencies. Also, executing queries on real-time data across those separate solutions’ data silos requires extensive and convoluted application code to be written – or may simply not be possible. While RegattaDB enables business to gain fast insights into both near-real-time and historical data, this is generally impossible with traditional solutions. Managing a variety of solutions requires familiarity with more products, handling a more complex set of intertwined solutions, which in turn requires more staff with that must be much more knowledgeable and experienced. All this translates into higher costs. Organizations’ data management requirements tend to evolve over time. However, having a plethora of databases, processes, and integrations hinders agility. The resulting rigidity makes it hard to make any significant changes without massive application code rewrites, acquisition of new skillsets, disruptive migrations, painful bugs, overprovisioning of compute, network, and storage infrastructure, and so forth. As opposed to the traditional approach, RegattaDB can store multiple types of data as well as perform transactional, analytical, and high-ingress workloads – and it can do them simultaneously. That eliminates the operational headaches of ETL, as well as the complexities of managing silos of data. In addition, it is possible to perform analytics on up-to-date data, without special efforts and added complexity in the application’s code. Such analytics could provide insights at real-time or close-to-real-time. Having a single universal database enables standardization of skills. Rather than having multiple product-specific specialists whose time and skills are limited to a single database, resulting in a few team members working overtime on their products while others’ time may be under-utilized, RegattaDB database team members can share workloads and be productive all the time. RegattaDB is cloud and platform-agnostic. It does not rely on third-party clustering systems thus improving deployment flexibility. RegattaDB supports a large variety of hardware configurations and supports any mix of server types in the same cluster. This is good news if you deploy RegattaDB on-premise and/or in the cloud, since this simplifies deployment and lowers TCO. RegattaDB supports standard SQL. SQL is the most popular and universal database language, and the most widely used relational database language. As such, most developers can start benefiting from RegattaDB straight away. Maybe even more importantly, SQL is a declarative language. This means that you only have to define “what you need” the database to do, and not “how exactly the database should achieve what you need” as in non-declarative languages that are provided by many NoSQL databases. Using SQL often results in dramatically shorter code. Furthermore, the developer does not need to bother with trying to find the optimal way for data retrieval. Instead, RegattaDB’s query optimizer takes care of all that. RegattaDB’s query optimizer uses “inside information” and various approaches to optimize data access and results. --- # RegattaDB linear scaling & no-compromise ACID in more detail Source: https://regatta.dev/blog/regatta-linear-scaling-and-no-compromise-acid-in-more-detail Published: 2023-10-26 Updated: 2026-10-06 Author: Chad Sakac Categories: Platform RegattaDB clusters scale from a single node to tens of thousands of nodes with hundreds of petabytes of data. Unlike traditional scale-out sharding, all of RegattaDB’s functionality - whether transactional or analytical - is always fully supported across the entire cluster, regardless of how data is distributed across the nodes. RegattaDB’s groundbreaking ACID technology allows distributed transactions to reach the strongest-possible serializable isolation-level with full external-consistency . Those properties are guaranteed across the entire cluster and therefore a transaction could safely span multiple nodes. Unlike the industry’s traditional consensus that achieving distributed strong transactional semantics must come at the expense of performance, RegattaDB’s innovative concurrency-control protocol, in combination with its advanced distributed mechanisms deliver strong transactions in distributed clusters at high performance. RegattaDB’s performance is linearly scalable – i.e., the more nodes you add, the higher the transaction-rate is. Strong ACID guarantees allow application developers to focus on business logic rather than on trying to accommodate for various failure scenarios and corner cases that are typical for databases that provide no or limited ACID guarantees, like for example eventually consistent databases or scale-out sharding databases that do not guarantee ACID across server boundaries across the entire cluster. In addition, RegattaDB fully supports more relaxed modes of isolation, such as are typically offered by MVCC relational databases – e.g., Read-Committed and Repeatable-Reads with (or without) First-Committer-Wins check. RegattaDB’s isolation-levels can be set per-transaction, and transactions of mixed isolation-levels can run concurrently. Furthermore, high-performance bulk ingress operations can enjoy various consistency guarantees without compromising the ingress rate. RegattaDB is designed to allowanalytical activities to run alongside transactions (https://regatta.dev/capabilities/real-time-olap-and-oltp/). For instance, fully consistent read-only queries on real-time data can run efficiently without blocking transactions in any way. --- # Private Company Spotlight Source: https://regatta.dev/resources/whitepapers/private-company-spotlight-william-blair Updated: 2026-09-02 Categories: Whitepapers Published byWilliam Blair’s Technology Groupand built around a Q&A with Regatta Data's cofounder and CEO Boaz Palgi, thisPrivate Company Spotlightprovides an external perspective on the RegattaDB database architecture and its relevance to real-time and agentic AI workloads. The paper highlights RegattaDB’s architectural advantage:a single engine for transactional, analytical, and vector workloads on the same live, strongly consistent data, at scale, performance, and efficiency. RegattaDB enables less data movement and infrastructure complexity, better resource efficiency, real-time insight from trusted data, and the scale and workload flexibility required by AI agent fleets. Customer examples illustrate how this architecture supports increasingly autonomous enterprise workloads. --- # Real-Time Stock Trading Analytics Demo with AI Agent Source: https://regatta.dev/resources/demos/real-time-stock-trading-analytics-demo-with-ai-agent Published: 2026-05-13 Updated: 2026-05-19 Categories: Demos Embed: https://player.vimeo.com/video/1191846738?&transparent=0&badge=0&autopause=0&player_id=0&app_id=58479 https://player.vimeo.com/video/1191846738?&transparent=0&badge=0&autopause=0&player_id=0&app_id=58479 This demo shows a real-time stock trading platform on a 10-node RegattaDB system. Trading applications stream millions of transactions while RegattaDB delivers extreme performance, running OLTP and OLAP together with no ETL or secondary systems. A Claude AI agent, connected via the Regatta MCP server, converts natural-language questions into distributed SQL analytics, producing live, high speed insights directly on current trading data in a single, scalable system. --- # Dirty Secrets of Sharding Whitepaper Source: https://regatta.dev/resources/whitepapers/dirty-secrets-of-sharding-whitepaper Published: 2025-05-19 Updated: 2026-08-31 Categories: Whitepapers Sharding single-node databases has trade-offs, often breaking developer expectations around ACID. This adds complexity to application code, forcing developers to attempt to solve database problems in their business logic. Learn why this happens, how it affects systems, and what can be done about it. CLICK TO DOWNLOAD (https://cdn.sanity.io/files/rgm91hol/production/f2f5a19fe6aeb5630895f3f596a4bf3576d9cd42.pdf) --- # Creating a Table and Inserting Data Source: https://regatta.dev/resources/how-to/creating-a-table-and-inserting-data Published: 2025-05-19 Updated: 2026-05-12 Categories: How-To Embed: https://player.vimeo.com/video/1066878273?badge=0&autopause=0&player_id=0&app_id=58479 https://player.vimeo.com/video/1066878273?badge=0&autopause=0&player_id=0&app_id=58479 A quick example on how to create a table in Regatta and insert data. --- # Creating a Regatta Cluster Source: https://regatta.dev/resources/how-to/creating-a-regatta-cluster Published: 2025-05-19 Updated: 2026-05-12 Categories: How-To Embed: https://player.vimeo.com/video/1066878165?badge=0&autopause=0&player_id=0&app_id=58479 https://player.vimeo.com/video/1066878165?badge=0&autopause=0&player_id=0&app_id=58479 Create a Regatta database using Regatta Cloud. --- # CRUD Operations Source: https://regatta.dev/resources/how-to/crud-operations Published: 2025-05-19 Updated: 2026-05-12 Categories: How-To Embed: https://player.vimeo.com/video/1066882211?badge=0&autopause=0&player_id=0&app_id=58479 https://player.vimeo.com/video/1066882211?badge=0&autopause=0&player_id=0&app_id=58479 Simple select, update and delete in a Regatta Database. --- # Linear Scaling Demo Source: https://regatta.dev/resources/demos/linear-scaling-demo Published: 2025-05-19 Updated: 2026-05-13 Categories: Demos Embed: https://player.vimeo.com/video/1066878518?badge=0&autopause=0&player_id=0&app_id=58479 https://player.vimeo.com/video/1066878518?badge=0&autopause=0&player_id=0&app_id=58479 A simple demonstration of the Regatta performance linear scaling. --- # Python Integration with Regatta Source: https://regatta.dev/resources/how-to/python-integration-with-regatta Published: 2025-05-19 Updated: 2026-05-12 Categories: How-To Embed: https://player.vimeo.com/video/1066881345?badge=0&autopause=0&player_id=0&app_id=58479 https://player.vimeo.com/video/1066881345?badge=0&autopause=0&player_id=0&app_id=58479 Example on deploying and using a Python driver. --- # Node.js Integration with Regatta Source: https://regatta.dev/resources/how-to/node-js-integration-with-regatta Published: 2025-05-19 Updated: 2026-05-12 Categories: How-To Embed: https://player.vimeo.com/video/1066879091?badge=0&autopause=0&player_id=0&app_id=58479 https://player.vimeo.com/video/1066879091?badge=0&autopause=0&player_id=0&app_id=58479 Learn how to deploy and use a Node.js driver with Regatta --- # Kafka Integration with Regatta Source: https://regatta.dev/resources/how-to/kafka-integration-with-regatta Published: 2025-05-19 Updated: 2026-07-14 Categories: How-To Embed: https://player.vimeo.com/video/1209760366?badge=0&autopause=0&player_id=0&app_id=58479 https://player.vimeo.com/video/1209760366?badge=0&autopause=0&player_id=0&app_id=58479 Ingress Data into Regatta using Kafka Sink Connector. --- # Build your JavaScript application with Regatta Source: https://regatta.dev/resources/demos/build-your-javascript-application-with-regatta Published: 2025-05-19 Updated: 2026-05-12 Categories: Demos Embed: https://player.vimeo.com/video/1066879497?badge=0&autopause=0&player_id=0&app_id=58479 https://player.vimeo.com/video/1066879497?badge=0&autopause=0&player_id=0&app_id=58479 Build your own JavaScript application using Regatta's custom drivers and connectors. --- # Demonstration: Regatta Linear Scaling Part II Source: https://regatta.dev/resources/demos/demonstration-regatta-linear-scaling-part-ii Published: 2025-05-19 Updated: 2026-05-12 Categories: Demos Embed: https://player.vimeo.com/video/955950638?badge=0&autopause=0&player_id=0&app_id=58479 https://player.vimeo.com/video/955950638?badge=0&autopause=0&player_id=0&app_id=58479 Regatta is a scale-out distributed SQL database that guarantees strong ACID with high, linearly scalable performance. Regatta uniquely enables long, complex OLAP queries to run alongside fast OLTP transactions on up-to-the-second transactional data. --- # Demonstration: Regatta Linear Scaling Part I Source: https://regatta.dev/resources/demos/demonstration-regatta-linear-scaling-part-i Published: 2025-05-19 Updated: 2026-05-12 Categories: Demos Embed: https://player.vimeo.com/video/955950287?badge=0&autopause=0&player_id=0&app_id=58479 https://player.vimeo.com/video/955950287?badge=0&autopause=0&player_id=0&app_id=58479 Regatta is a scale-out distributed SQL database that guarantees strong ACID with high, linearly scalable performance. Regatta uniquely enables long, complex OLAP queries to run alongside fast OLTP transactions on up-to-the-second transactional data. --- # Demonstration: Integrating Regatta with Streaming/Event Data Source: https://regatta.dev/resources/demos/demonstration-integrating-regatta-with-streaming-event-data Published: 2025-05-19 Updated: 2026-05-12 Categories: Demos Embed: https://player.vimeo.com/video/955951162?badge=0&autopause=0&player_id=0&app_id=58479 https://player.vimeo.com/video/955951162?badge=0&autopause=0&player_id=0&app_id=58479 Streaming and event use cases are all around us, and great solutions like Kafka for event data exist and are mature. What’s not easy (until now) is integrating streaming event data and transactional relational data at scale, and reasoning over the unbounded stream at scale… in real-time. Regatta is a simple and effective solution for these scenarios. --- # RegattaDB: High-Performance Database Built for Agentic AI Source: https://saastake.com/regattadb-ai-agents/ Updated: 2026-10-01 Type: External coverage SaaSTake spoke with Regatta CEO Boaz Palgi about what happens when thousands of AI Agents hit the same database, and why RegattaDB was built for that moment. --- # Private Company Spotlight Source: https://regatta.dev/resources/whitepapers/private-company-spotlight-william-blair Updated: 2026-09-08 Type: External coverage What kind of infrastructure does it actually take to run fleets of autonomous AI agents? A new William Blair Spotlight breaks down RegattaDB’s single-engine architecture—and why unifying live data processing is the key to real-time enterprise intelligence --- # Unifying Data Stacks, Open-Weight Controversies & Google's Anti-Gravity CLI Source: https://agentsofdev.podbean.com/e/unifying-data-stacks-open-weight-controversies-googles-anti-gravity-cli-agents-of-dev-episode-32/ Published: 2026-08-06 Updated: 2026-08-24 Type: External coverage “The reason why it works is this funky, unique, what is it called, concurrency control mechanism, So basically, how you handle requests at scale, simultaneously, to the database, and they can then get to hundreds of millions of events per second in this thing without dropping." --- # RegattaDB Arrives: A Unified Engine Built for the Era of Read-Write AI Source: https://futurumgroup.com/insights/regattadb-arrives-a-unified-engine-built-for-the-era-of-read-write-ai/ Published: 2026-07-17 Updated: 2026-08-24 Type: External coverage "Regatta’s pure scale-out architecture is an interesting technical differentiator for RegattaDB." --- # Regatta Data Launches RegattaDB for AI Agent Workloads Source: https://dailyaibrief.com/news/regatta-data-launches-regattadb-for-ai-agent-workloads-xMsdhNn4 Published: 2026-07-16 Updated: 2026-08-24 Type: External coverage "The platform combines capabilities for transaction processing, analytics, and vector search, aiming to give AI agents a unified view of data at scale." --- # AI Database War Begins: Is RegattaDB the Breakthrough That Could Finally Replace Legacy Data Systems? Source: https://thesiliconreview.com/2026/07/ai-database-regattadb-vector-database-ai-agents Published: 2026-07-16 Updated: 2026-08-24 Type: External coverage "RegattaDB launches at a time when enterprises are racing to deploy AI agents capable of reasoning, analyzing, and making decisions." --- # Regatta Data launches unified base for AI with RegattaDB Source: https://www.techtarget.com/data-technologies/news/366645786/Regatta-Data-launches-unified-base-for-AI-with-RegattaDB Published: 2026-07-15 Updated: 2026-08-24 Type: External coverage "For organizations deploying AI agents at scale, this means they can finally support the massive concurrency and real-time demands of agent workloads without the fragmentation and latency issues that plague traditional architectures..." --- # Regatta launches its unified OLTP, OLAP and vector database Source: https://www.blocksandfiles.com/data-management/2026/07/15/regatta-launches-its-unified-oltp-olap-and-vector-database/5271769 Published: 2026-07-15 Updated: 2026-08-24 Type: External coverage A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. --- # RegattaDB Launches as the Database Built for AI Agents - Unifying OLTP, OLAP, and Vectors Source: https://finance.yahoo.com/technology/ai/articles/regattadb-launches-database-built-ai-123300321.html Published: 2026-07-15 Updated: 2026-08-24 Type: External coverage "Agents need to think, reason, and act on live data simultaneously, which means they need real-time execution of transactions (OLTP), analytics (OLAP), and semantic context (Vectors) across millions of concurrent instances." --- # Dell PowerFlex/Regatta database combo overcomes trad database limitations Source: https://www.blocksandfiles.com/data-management/2025/11/06/dell-powerflex/regatta-database-combo-overcomes-trad-database-limitations/1616674 Published: 2025-11-06 Updated: 2026-08-24 Type: External coverage A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. --- # Flash-centric Regatta OLxP database working on faster access for AI agents Source: https://www.blocksandfiles.com/ai-ml/2025/02/04/flash-centric-regatta-olxp-database-working-on-faster-access-for-ai-agents/1605631 Published: 2025-02-04 Updated: 2026-08-24 Type: External coverage A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. --- # Database startup Regatta emerges from stealth mode Source: https://www.blocksandfiles.com/data-management/2024/03/21/database-startup-regatta-emerges-from-stealth-mode/1608172 Published: 2024-03-21 Updated: 2026-08-24 Type: External coverage A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus. A short quote from the article Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi eros lectus, vehicula id lacus ac, iaculis cursus lacus.