Building a multi-Region API with Prisma ORM and Amazon Aurora DSQL
In this post, we show how you can build a multi-Region active-active API using Prisma ORM and Amazon Aurora DSQL.
July 21, 2026
AI-powered incident analysis for Amazon RDS using automated forensic artifacts
In this post, we demonstrate a serverless approach to continuous forensic artifact collection for Amazon RDS and Amazon Aurora databases. By capturing point-in-time snapshots of database internals on a cadence and storing them in Amazon S3, you create a time-series record that AI tools can analyze in seconds. This turns what was hours of manual investigation into an instant conversation.
Migrating mission-critical payments at Nubank to Amazon Aurora PostgreSQL
Managing payment infrastructure at scale presents unique challenges that impact both performance and operational efficiency. In this post, we share the technical and operational challenges Nubank faced with self-managed PostgreSQL, the evaluation criteria they established for selecting database solutions, and the results from their successful migration to Amazon Aurora PostgreSQL-Compatible Edition. Nubank achieved up to 1,900x query performance improvements in specific cases.
Cypher graph queries on PostgreSQL with Apache AGE
The cover image above compares two representations of the same data model, separated by more than 45 years: one shows a PostgreSQL extension for Visual Studio Code visualizing a graph with Apache AGE, and the other displays the employee hierarchy from the Oracle 2.3 User Guide. Hierarchical and graph traversal queries have long been a topic in relational databases. Early SQL, or SEQUEL, used employee-department and manager relationships, which led to the need for graph traversal syntax beyond self-joins. The first commercial RDBMS had a CONNECT BY syntax (see Oracle 2.3 User Guide), later replaced by recursive WITH clauses in the SQL standard. PostgreSQL 19 adds SQL/PGQ support for property graph queries. Meanwhile, NoSQL graph databases like Neo4j, with Cypher, have gained popularity, and this capability is now accessible in PostgreSQL via the Apache AGE extension.
Apache AGE on PostgreSQL
I've built a small example based on the legendary EMP-DEPT schema from 45 years ago, running on Azure, because, according to https://www.pgextensions.org/, it is the only managed service that supports it:
I'm using HorizonDB, the PostgreSQL-compatible managed service for enterprise workloads, which is currently in preview (but you can also use the free ghcr.io/pglayers/pglayers-azure:17 image from pglayers). I've enabled Apache AGE by adding it to the azure.extensions list:
postgres=> \dconfig azure.extensions
List of configuration parameters
Parameter | Value
------------------+----------------------------------------------
azure.extensions | pg_diskann,vector,pg_textsearch,azure_ai,age
postgres=> \dconfig server_version
List of configuration parameters
Parameter | Value
----------------+-----------------------------------------------
server_version | 17.9 (Azure HorizonDB (81895d42565)(release))
The example is deliberately straightforward. Besides the departments reference, it includes the employee entity, and one relationship: each employee's immediate manager. In the relational model, both are stored in the same table, with the manager relationship represented through a self-referencing foreign key. SQL handles such relationships using joins, with CONNECT BY or WITH RECURSIVE for graph structures. Apache AGE represents relationships as graph edges and supports openCypher syntax, significantly simplifying complex graph queries.
Graph model
Property graph databases model the same information differently than relational databases. Entities are represented as nodes (aka vertices), and relationships (aka edges) connect them. Rather than reconstructing relationships through joins, relationships are stored explicitly as graph edges and traversed using graph patterns.
I install the extension and set the search path to include ag_catalog with the Apache AGE functions and datatypes:
create extension if not exists age;
set search_path = "$user", public, ag_catalog;
I generate a graph, which is equivalent to a schema:
select create_graph('emp_dept_graph');
PostgreSQL can now execute Cypher queries against this graph by calling cypher() with the graph name and query, returning an agtype result.
Graph nodes (vertices () )
In Apache AGE, all Cypher queries are in dollar-quoted strings. The following creates the nodes for the departments:
select * from cypher('emp_dept_graph', $openCypher$
CREATE
(:Department { deptno:10, name:"Administration", loc:"New York" }),
(:Department { deptno:20, name:"Research", loc:"San Francisco" }),
(:Department { deptno:30, name:"Sales", loc:"Chicago" }),
(:Department { deptno:40, name:"Operations", loc:"Boston" })
$openCypher$) AS (result agtype);
The parentheses () draw a node (think of an ASCII art version of a graph), (:Department) adds a label to it, and the JSON-like { deptno:40, name:'Operations', loc:'Boston'} adds properties as key-value pairs, similar to JSON.
I do the same to create the employees, without specifying their department, only their own properties:
select * from cypher('emp_dept_graph', $openCypher$
CREATE
(:Employee {empno:7839,name:"OATES",job:"President",sal:5000}),
(:Employee {empno:7566,name:"JONES",job:"Manager",sal:2975}),
(:Employee {empno:7698,name:"BLAKE",job:"Manager",sal:2850}),
(:Employee {empno:7782,name:"CLARK",job:"Manager",sal:2450}),
(:Employee {empno:7788,name:"SCOTT",job:"Analyst",sal:3000}),
(:Employee {empno:7902,name:"FORD",job:"Analyst",sal:3000}),
(:Employee {empno:7999,name:"WILSON",job:"Analyst",sal:2800}),
(:Employee {empno:7876,name:"ADAMS",job:"Clerk",sal:1100}),
(:Employee {empno:7369,name:"SMITH",job:"Clerk",sal:800}),
(:Employee {empno:8000,name:"JAKES",job:"Clerk",sal:1000}),
(:Employee {empno:7499,name:"ALLEN",job:"Salesman",sal:1600}),
(:Employee {empno:7521,name:"WARD",job:"Salesman",sal:1250}),
(:Employee {empno:7654,name:"MARTIN",job:"Salesman",sal:1250}),
(:Employee {empno:7844,name:"TURNER",job:"Salesman",sal:1500}),
(:Employee {empno:7900,name:"JAMES",job:"Clerk",sal:950}),
(:Employee {empno:8001,name:"CARTER",job:"Salesman",sal:1400}),
(:Employee {empno:7934,name:"MILLER",job:"Clerk",sal:1300})
$openCypher$) AS (result agtype);
The nodes are stored with their properties. Now I can define the relationships to form a graph.
Graph relationships (edges -[]->)
I'll add the relationship to show where an employee works in a department, and their position in the hierarchy.
In a SQL model, employees reference their department via a DEPTNO foreign key and their manager through an MGR foreign key, with the manager being another employee. In relational databases, relationships are represented by key values rather than direct pointers between rows, and entities are independent of the navigation between them. Instead, the department number and manager's employee number are attributes of the employee entity, and relationships are established during queries with joins. Simple many-to-one relationships are represented by foreign keys. However, more complex relationships, such as many-to-many relationships or relationships with their own attributes, require an additional association table.
In a graph database, relationships are at the core of the model. The nodes are the entities and the edges are the relationships. In ASCII art, this can be described as: (:Employee)-[:WORKS_IN]->(:Department).
In SQL, relationships are queried using joins, and prior to the JOIN syntax, they were expressed as a Cartesian product in the FROM clause, with a WHERE clause to filter the desired combinations. A similar approach applies here. To establish the employee-department relationship, I define the set of (:Employee), (:Department) pairs that represent where each employee works and create a -[:WORKS_IN]-> edge between them.
select * from cypher('emp_dept_graph', $openCypher$
MATCH (e:Employee),(d:Department)
WHERE
(e.empno=7839 AND d.deptno=10)
OR (e.empno=7782 AND d.deptno=10)
OR (e.empno=7934 AND d.deptno=10)
OR (e.empno=7566 AND d.deptno=20)
OR (e.empno=7788 AND d.deptno=20)
OR (e.empno=7902 AND d.deptno=20)
OR (e.empno=7369 AND d.deptno=20)
OR (e.empno=7876 AND d.deptno=20)
OR (e.empno=7999 AND d.deptno=20)
OR (e.empno=8000 AND d.deptno=20)
OR (e.empno=7698 AND d.deptno=30)
OR (e.empno=7499 AND d.deptno=30)
OR (e.empno=7521 AND d.deptno=30)
OR (e.empno=7654 AND d.deptno=30)
OR (e.empno=7844 AND d.deptno=30)
OR (e.empno=7900 AND d.deptno=30)
OR (e.empno=8001 AND d.deptno=30)
CREATE (e)-[:WORKS_IN]->(d)
$openCypher$) AS (result agtype);
Here is a similar query to declare the employee-manager relationship as (:Employee)-[:REPORTS_TO ]->(:Employee):
select * from cypher('emp_dept_graph', $openCypher$
MATCH (e:Employee),(m:Employee)
WHERE
(e.empno=7566 AND m.empno=7839)
OR (e.empno=7698 AND m.empno=7839)
OR (e.empno=7782 AND m.empno=7839)
OR (e.empno=7788 AND m.empno=7566)
OR (e.empno=7902 AND m.empno=7566)
OR (e.empno=7999 AND m.empno=7566)
OR (e.empno=7876 AND m.empno=7788)
OR (e.empno=7369 AND m.empno=7902)
OR (e.empno=8000 AND m.empno=7999)
OR (e.empno=7499 AND m.empno=7698)
OR (e.empno=7521 AND m.empno=7698)
OR (e.empno=7654 AND m.empno=7698)
OR (e.empno=7844 AND m.empno=7698)
OR (e.empno=7900 AND m.empno=7698)
OR (e.empno=8001 AND m.empno=7698)
OR (e.empno=7934 AND m.empno=7782)
CREATE (e)-[:REPORTS_TO { manager_level: 1 }]->(m)
$openCypher$ ) AS (result agtype);
To show an example of a relationship property, I've added the manager level using Cypher map syntax, which looks like JSON.
AGE Internals
Apache AGE stores metadata in two catalog tables:
postgres=> select * from ag_catalog.ag_graph
;
graphid | name | namespace
---------+----------------+----------------
26064 | emp_dept_graph | emp_dept_graph
(1 row)
postgres=> select * from ag_catalog.ag_label
;
name | graph | id | kind | relation | seq_name
------------------+-------+----+------+---------------------------------+-------------------------
_ag_label_vertex | 26064 | 1 | v | emp_dept_graph._ag_label_vertex | _ag_label_vertex_id_seq
_ag_label_edge | 26064 | 2 | e | emp_dept_graph._ag_label_edge | _ag_label_edge_id_seq
Department | 26064 | 3 | v | emp_dept_graph."Department" | Department_id_seq
Employee | 26064 | 4 | v | emp_dept_graph."Employee" | Employee_id_seq
WORKS_IN | 26064 | 5 | e | emp_dept_graph."WORKS_IN" | WORKS_IN_id_seq
REPORTS_TO | 26064 | 6 | e | emp_dept_graph."REPORTS_TO" | REPORTS_TO_id_seq
(6 rows)
The data is stored in nodes and edges tables:
postgres=> \d emp_dept_graph."Department"
Table "emp_dept_graph.Department"
Column | Type | Collation | Nullable | Default
------------+---------+-----------+----------+-----------------------------------------------------------------------------------------------------------------------------------
id | graphid | | not null | _graphid(_label_id('emp_dept_graph'::name, 'Department'::name)::integer, nextval('emp_dept_graph."Department_id_seq"'::regclass))
properties | agtype | | not null | agtype_build_map()
Indexes:
"Department_pkey" PRIMARY KEY, btree (id)
Inherits: emp_dept_graph._ag_label_vertex
postgres=> select * from emp_dept_graph."Department"
;
id | properties
-----------------+---------------------------------------------------------------------------------------------
844424930131969 | {"loc": "New York", "name": "Administration", "deptno": 10, "disp_label": "Administration"}
844424930131970 | {"loc": "San Francisco", "name": "Research", "deptno": 20, "disp_label": "Research"}
844424930131971 | {"loc": "Chicago", "name": "Sales", "deptno": 30, "disp_label": "Sales"}
844424930131972 | {"loc": "Boston", "name": "Operations", "deptno": 40, "disp_label": "Operations"}
(4 rows)
postgres=> \d emp_dept_graph."WORKS_IN"
Table "emp_dept_graph.WORKS_IN"
Column | Type | Collation | Nullable | Default
------------+---------+-----------+----------+-------------------------------------------------------------------------------------------------------------------------------
id | graphid | | not null | _graphid(_label_id('emp_dept_graph'::name, 'WORKS_IN'::name)::integer, nextval('emp_dept_graph."WORKS_IN_id_seq"'::regclass))
start_id | graphid | | not null |
end_id | graphid | | not null |
properties | agtype | | not null | agtype_build_map()
Indexes:
"WORKS_IN_end_id_idx" btree (end_id)
"WORKS_IN_start_id_idx" btree (start_id)
Inherits: emp_dept_graph._ag_label_edge
postgres=> select * from emp_dept_graph."WORKS_IN"
;
id | start_id | end_id | properties
------------------+------------------+-----------------+------------
1407374883553281 | 1125899906842625 | 844424930131969 | {}
1407374883553282 | 1125899906842626 | 844424930131970 | {}
1407374883553283 | 1125899906842627 | 844424930131971 | {}
1407374883553284 | 1125899906842628 | 844424930131969 | {}
1407374883553285 | 1125899906842629 | 844424930131970 | {}
1407374883553286 | 1125899906842630 | 844424930131970 | {}
1407374883553287 | 1125899906842631 | 844424930131970 | {}
1407374883553288 | 1125899906842632 | 844424930131970 | {}
1407374883553289 | 1125899906842633 | 844424930131970 | {}
1407374883553290 | 1125899906842634 | 844424930131970 | {}
1407374883553291 | 1125899906842635 | 844424930131971 | {}
1407374883553292 | 1125899906842636 | 844424930131971 | {}
1407374883553293 | 1125899906842637 | 844424930131971 | {}
1407374883553294 | 1125899906842638 | 844424930131971 | {}
1407374883553295 | 1125899906842639 | 844424930131971 | {}
1407374883553296 | 1125899906842640 | 844424930131971 | {}
1407374883553297 | 1125899906842641 | 844424930131969 | {}
(17 rows)
Looking at the table definitions, I can prevent duplicates by creating the following UNIQUE indexes:
CREATE UNIQUE INDEX department_deptno_uix
ON emp_dept_graph."Department"
(
(agtype_access_operator(properties, '"deptno"'))
);
CREATE UNIQUE INDEX employee_empno_uix
ON emp_dept_graph."Employee"
(
(agtype_access_operator(properties, '"empno"'))
);
CREATE UNIQUE INDEX works_in_uix
ON emp_dept_graph."WORKS_IN"(start_id,end_id);
CREATE UNIQUE INDEX reports_to_uix
ON emp_dept_graph."REPORTS_TO"(start_id,end_id);
I can also create a GIN index on the properties to accelerate searches by a property value:
CREATE INDEX employee_properties_gin
ON emp_dept_graph."Employee"
USING gin (properties);
Let's examine some queries and their corresponding translations on internal tables and indexes.
Query
I have already used the MATCH clause to identify the combinations of employees and departments to create the edges.
To find the manager of Jones (:Employee {name:"JONES"}), I match the relationship with a variable -[:REPORTS_TO]->(manager) and return manager.name property.
postgres=> SELECT * FROM cypher('emp_dept_graph', $openCypher$
MATCH (:Employee {name:"JONES"})-[:REPORTS_TO]->(manager)
RETURN manager.name
$openCypher$) AS (
manager agtype
);
manager
---------
"OATES"
(1 row)
I can add the department of the manager to the result by navigating through -[:WORKS_IN]->:
postgres=> SELECT *
FROM cypher('emp_dept_graph', $openCypher$
MATCH (:Employee {name:"JONES"})
-[:REPORTS_TO]->(manager)
-[:WORKS_IN]->(department)
RETURN manager.name, department.name
$openCypher$) AS (
manager agtype,
department agtype
);
manager | department
---------+------------------
"OATES" | "Administration"
(1 row)
I can get the manager's manager with -[:REPORTS_TO]->()-[:REPORTS_TO]->(manager) but also with -[:REPORTS_TO*2]->:
postgres=> SELECT *
FROM cypher('emp_dept_graph', $openCypher$
MATCH (:Employee {name:"JAKES"})-[:REPORTS_TO*2]->(manager)
RETURN manager.name
$openCypher$) AS <... (truncated)
July 20, 2026
Connection pooling strategies in Amazon Aurora DSQL
In this post, you’ll learn four concrete strategies that help you reduce Aurora DSQL connection overhead, stay within the 100-connections-per-second rate limit, and avoid thundering-herd reconnection storms. By the end, you’ll have a production-ready checklist for configuring connection pools that support reliable performance at scale.
Every UPDATE Leaves a Ghost: MVCC, Bloat, and VACUUM in PostgreSQL
What happens to old row versions after nobody needs them? They become dead tuples, and over time they bloat your tables. Go deeper into PostgreSQL MVCC with runnable psql examples.
July 17, 2026
DocumentDB on YugabyteDB
The DocumentDB extension, providing MongoDB compatibility for PostgreSQL, is available in preview in YugabyteDB 2026.1, with some limitations, such as the absence of secondary indexes and lack of support for ARM processors. Still, it's interesting to see how it works.
I've launched a Docker container from the image containing version 2026.1.0.0, build 118:
docker run --rm -it -p 27017:27017 -p 15433:15433 \
yugabytedb/yugabyte:latest bash
I started one node, setting the necessary flags:
yugabyted start \
--master_flags="allowed_preview_flags_csv=ysql_enable_documentdb,ysql_enable_documentdb=true,enable_pg_cron=true" \
--tserver_flags="allowed_preview_flags_csv=ysql_enable_documentdb,ysql_enable_documentdb=true,enable_pg_cron=true" \
--ui=true
The DocumentDB offers a MongoDB-compatible endpoint; however, to observe the internals, I used the PostgreSQL client:
ysqlsh -h $HOSTNAME
From the PostgreSQL client, I used the DocumentDB API to run MongoDB-compatible commands from SQL. I imported a collection with ten thousand documents, each including a nested array of one hundred items:
create extension if not exists documentdb cascade;
select documentdb_api.drop_collection ('db','coll1');
select documentdb_api.create_collection ('db','coll1');
with docs(document) as (select
json_build_object(
'_id', n,
'field1', n%100,
'field2', md5(random()::text),
'field3', md5(random()::text),
'field4', md5(random()::text),
'field5', md5(random()::text),
'array', (
select json_agg(child.id+ case when n%3=0 then 0 else random() end)
from generate_series(1, 1e2) AS child(id)
)
) from generate_series(1, 1e5) n
)
select count(documentdb_api.insert_one ('db','coll1',
document::text::documentdb_core.bson
)) from docs;
;
I check a sample of data:
set documentdb_core.bsonUseEJson to true;
\pset pager off
select document from documentdb_api_catalog.bson_aggregation_pipeline(
'db', '{"aggregate": "coll1", "pipeline": [
{"$limit": 2 }
], "cursor": {}}'::documentdb_core.bson
);
Result:
document
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{ "_id" : { "$numberInt" : "78047" }, "field1" : { "$numberInt" : "47" }, "field2" : "61160c5889651c7aeb9b53c9e8c16874", "field3" : "a5643ebcf7b4cb52ce5606347a48159d", "field4" : "1920dadda82764003c8666396927d184", "field5" : "38981fb4fe2874a16e71adb91eaf80b7", "array" : [ { "$numberDouble" : "1.6680338007661099642" }, { "$numberDouble" : "2.0321660675583723688" }, { "$numberDouble" : "3.7248612825324078912" }, { "$numberDouble" : "4.6682151188376419526" }, { "$numberDouble" : "5.352836859518445678" }, { "$numberDouble" : "6.1549238121424405534" }, { "$numberDouble" : "7.5698744025959001647" }, { "$numberDouble" : "8.3627292359089526741" }, { "$numberDouble" : "9.7284070730559299989" }, { "$numberDouble" : "10.648505386329139455" }, { "$numberDouble" : "11.819375264988172702" }, { "$numberDouble" : "12.564692810410857504" }, { "$numberDouble" : "13.578234292227129743" }, { "$numberDouble" : "14.840940698922509" }, { "$numberDouble" : "15.000110832002331307" }, { "$numberDouble" : "16.358619841052682631" }, { "$numberDouble" : "17.114466577365092803" }, { "$numberDouble" : "18.453576775946736177" }, { "$numberDouble" : "19.612164960288463789" }, { "$numberDouble" : "20.763510570791428478" }, { "$numberDouble" : "21.072906780595499043" }, { "$numberDouble" : "22.302558940939842813" }, { "$numberDouble" : "23.028762426311956801" }, { "$numberDouble" : "24.977457545570718622" }, { "$numberDouble" : "25.168495224042882086" }, { "$numberDouble" : "26.683268805530829582" }, { "$numberDouble" : "27.603359814890115587" }, { "$numberDouble" : "28.878206328994565411" }, { "$numberDouble" : "29.721073180897786159" }, { "$numberDouble" : "30.626948384420241922" }, { "$numberDouble" : "31.671570586699115069" }, { "$numberDouble" : "32.662353414214038594" }, { "$numberDouble" : "33.46460769319755002" }, { "$numberDouble" : "34.940574677532538317" }, { "$numberDouble" : "35.970141769064831294" }, { "$numberDouble" : "36.179330236215683669" }, { "$numberDouble" : "37.600489143561993899" }, { "$numberDouble" : "38.84836254286827284" }, { "$numberDouble" : "39.212520619284028101" }, { "$numberDouble" : "40.552350139480068947" }, { "$numberDouble" : "41.534399323092017653" }, { "$numberDouble" : "42.675192781144495768" }, { "$numberDouble" : "43.897435440034712428" }, { "$numberDouble" : "44.643362479639151275" }, { "$numberDouble" : "45.079069764447424973" }, { "$numberDouble" : "46.571893792280704361" }, { "$numberDouble" : "47.247632193766989417" }, { "$numberDouble" : "48.490043046330811194" }, { "$numberDouble" : "49.453768298556425975" }, { "$numberDouble" : "50.918392174574123032" }, { "$numberDouble" : "51.920252310666860751" }, { "$numberDouble" : "52.939591943997093892" }, { "$numberDouble" : "53.620526333881137759" }, { "$numberDouble" : "54.692199233976516837" }, { "$numberDouble" : "55.398818854086997021" }, { "$numberDouble" : "56.650202658333142836" }, { "$numberDouble" : "57.70283083519552747" }, { "$numberDouble" : "58.48719280187031444" }, { "$numberDouble" : "59.932029859433328056" }, { "$numberDouble" : "60.435350057667704959" }, { "$numberDouble" : "61.796201961995798513" }, { "$numberDouble" : "62.883084798688862804" }, { "$numberDouble" : "63.070790792109328038" }, { "$numberDouble" : "64.16759516733826274" }, { "$numberDouble" : "65.684735624962627298" }, { "$numberDouble" : "66.406523484084644338" }, { "$numberDouble" : "67.628489973539217317" }, { "$numberDouble" : "68.548155362022797021" }, { "$numberDouble" : "69.446152335761937024" }, { "$numberDouble" : "70.850816173934148878" }, { "$numberDouble" : "71.371987666701940611" }, { "$numberDouble" : "72.231763790086574772" }, { "$numberDouble" : "73.057257769223340915" }, { "$numberDouble" : "74.248606955094231807" }, { "$numberDouble" : "75.734788957354354011" }, { "$numberDouble" : "76.261763568307117112" }, { "$numberDouble" : "77.366290387804127704" }, { "$numberDouble" : "78.090952646323614772" }, { "$numberDouble" : "79.907761062715451317" }, { "$numberDouble" : "80.213292529749651294" }, { "$numberDouble" : "81.40122970782175571" }, { "$numberDouble" : "82.397874716128853834" }, { "$numberDouble" : "83.856288865693912271" }, { "$numberDouble" : "84.836437448365771274" }, { "$numberDouble" : "85.712489576106221989" }, { "$numberDouble" : "86.344972416913108759" }, { "$numberDouble" : "87.838719804924522805" }, { "$numberDouble" : "88.736218332587981195" }, { "$numberDouble" : "89.061374463030290372" }, { "$numberDouble" : "90.181943740431705692" }, { "$numberDouble" : "91.370555458410805727" }, { "$numberDouble" : "92.540259312764803212" }, { "$numberDouble" : "93.151492898837148005" }, { "$numberDouble" : "94.45972723544899452" }, { "$numberDouble" : "95.041905493739093913" }, { "$numberDouble" : "96.099361464158789659" }, { "$numberDouble" : "97.057660017948322206" }, { "$numberDouble" : "98.420677137980504767" }, { "$numberDouble" : "99.694426199374930775" }, { "$numberDouble" : "100.28095505763631934" } ] }
{ "_id" : { "$numberInt" : "84564" }, "field1" : { "$numberInt" : "64" }, "field2" : "e14fc6847516bbae0055d5e29a8331db", "field3" : "0d91f561a9af719b173283826fff7dc9", "field4" : "7c7009c2b6b2d63ada1f3c84ee9e55dc", "field5" : "43d6dbdb0613c6ed6979b797fd693c9a", "array" : [ { "$numberInt" : "1" }, { "$numberInt" : "2" }, { "$numberInt" : "3" }, { "$numberInt" : "4" }, { "$numberInt" : "5" }, { "$numberInt" : "6" }, { "$numberInt" : "7" }, { "$numberInt" : "8" }, { "$numberInt" : "9" }, { "$numberInt" : "10" }, { "$numberInt" : "11" }, { "$numberInt" : "12" }, { "$numberInt" : "13" }, { "$numberInt" : "14" }, { "$numberInt" : "15" }, { "$numberInt" : "16" }, { "$numberInt" : "17" }, { "$numberInt" : "18" }, { "$numberInt" : "19" }, { "$numberInt" : "20" }, { "$numberInt" : "21" }, { "$numberInt" : "22" }, { "$numberInt" : "23" }, { "$numberInt" : "24" }, { "$numberInt" : "25" }, { "$numberInt" : "26" }, { "$numberInt" : "27" }, { "$numberInt" : "28" }, { "$numberInt" : "29" }, { "$numberInt" : "30" }, { "$numberInt" : "31" }, { "$numberInt" : "32" }, { "$numberInt" : "33" }, { "$numberInt" : "34" }, { "$numberInt" : "35" }, { "$numberInt" : "36" }, { "$numberInt" : "37" }, { "$numberInt" : "38" }, { "$numberInt" : "39" }, { "$numberInt" : "40" }, { "$numberInt" : "41" }, { "$numberInt" : "42" }, { "$numberInt" : "43" }, { "$numberInt" : "44" }, { "$numberInt" : "45" }, { "$numberInt" : "46" }, { "$numberInt" : "47" }, { "$numberInt" : "48" }, { "$numberInt" : "49" }, { "$numberInt" : "50" }, { "$numberInt" : "51" }, { "$numberInt" : "52" }, { "$numberInt" : "53" }, { "$numberInt" : "54" }, { "$numberInt" : "55" }, { "$... (truncated)
July 16, 2026
Unified Logs is now in open beta
One searchable view for logs across every Supabase service, with live tail, filtering, and a timeline.
July 15, 2026
Announcing VillageSQL Server 0.0.5
Announcing VillageSQL Server 0.0.5: in-place extension upgrades, version pinning, variable-length custom types, and statement hooks.
PostgreSQL Meta Commands that save time every day
When most people start working with PostgreSQL, they quickly learn SQL: [crayon-6a5789801521c171008655/] But very soon, another world opens up inside psql — a set of commands that don’t look like SQL, don’t end with semicolons. These are PostgreSQL Meta Commands, and they quietly power the daily workflow of almost every experienced DBA. Meta commands are … Continued
The post PostgreSQL Meta Commands that save time every day appeared first on Percona.
Leaving Buffalo: A Move-ing Story
Moving is not for the faint of heart! The surgeon general should issue a warning against moving houses after age 50. Coordinating our cross-country move was one of the hardest thing I had done. Selling our house in Buffalo, finding a suitable rental house in the Bay Area, figuring out the logistics of the move, getting rid of the furniture we wouldn't transport, boxing everything up, and then on the other side unboxing everything and buying new furniture... It was simply exhausting.
Our move has been a long time in the works. For the last 6 years I have been working remotely, first for AWS and then for MongoDB Research, and I have been telling people I would move out of Buffalo any day now. Indeed we could have moved earlier, but we kept putting it off. We waited until my son finished high school, then tried to move last summer. But we got the house on the market too late and it fell through. By then I had already told people I was moving, including an entire table at OSDI 2025. So for this final attempt, I used the Russian approach and kept quiet until it was done. (As the story goes, the Soviet space program announced only the missions that succeeded, and stayed quiet about the ones that didn't.)
Escaping Buffalo's Gravity
I have been in Buffalo for 21 years, not counting two sabbaticals. That's a long time to stay in one place. Call it inertia or bad luck, but after so many stalled attempts I started to suspect that Buffalo had the escape velocity of a black hole. When I named my blog muratbuffalo, I didn't know the name would stick and almost become a curse.
I lived through 21 of the Buffalo winters, and they are tough. I remember one particularly bad one when the roads were covered with ice for a good 3 weeks and looked like Siberia (well, at least like what I imagine Siberia looks like, since I haven't been). There is virtually no sun during winter, and it gets bleak. I think I developed a seasonal affective disorder without even realizing it. I only caught on when my manager, after reading a post I wrote in February 2025, told me to take a couple of days off.
If you are lucky enough to survive the winter (some people don't, seriously), you are rewarded with an unfamiliar bright orb in the sky come May. You get a couple of weeks of spring, and then you spring straight into summer, where it gets hot very quickly. Buffalo is humid too, so 80-90 degrees feels much hotter than it should. I am afraid I might be dragging this cursed humidity to the Bay Area with me, like Rob McKenna, the miserable Rain God lorry driver in Douglas Adams’s So Long, and Thanks for All the Fish.
The weather was only part of the reason. Buffalo is also not a big city. Every time I traveled to a proper big city like NYC, Seattle, or even Boston, I felt how much of the big-city action and energy we were missing.
But the biggest reason was family. My son Ahmet was already out in California. He had gone there for college, and then pivoted (as one does in California) to start his AI company. If we wanted to spend more time together as a family, this was the time and the place. We also figured the Bay Area, with all its opportunities, would be good for our two daughters' education and growth.
I am not claiming the Bay Area is all awesome, or that it beats Buffalo in every respect. I don't wear rose-tinted glasses. But one thing was clear: after 21 years, it was time to leave. Buffalo had come to feel routine, and change is good.
In Buffalo's defense, it was a great place to raise the kids, and I had good colleagues at CSE Buffalo and many fond memories. As Pat Helland liked to joke whenever I mentioned my plans to move out, "Buffalo is a great place to come from".
Oops, I did it again! Another cross-country trip
We were not going to take much furniture. Ours had been with us for a long time, and we wanted a fresh start there too. But even when you don't take much furniture, a family household depends on a surprising number of things that all need to be transported.
I realized this during our first move inside Buffalo. It felt like every closet in the house was springing with stuff, and no amount of boxing and cleaning got us to an empty house. Even knowing this, I got surprised again on every move since, including this last one. We sold, donated, and threw away so much stuff, I can't believe it. It turns out I keep wearing the same 3-5 things, and I found clothes I hadn't worn in more than 10 years.
I looked up the Pods moving solution, and it was ridiculously expensive: starting at $4K just to transport the Pod to the Bay Area, and dropped off (inshallah?) at a time they couldn't guarantee... These guys have higher margins than NVIDIA!
Then I looked at U-Haul. My 2022 Highlander came with a hitch included, and a U-Haul 12-by-6-foot trailer would solve our moving problem. It was surprisingly cheap, only $350 for a 9-day cross-country trip. So, somehow we were crazy enough to attempt another transcontinental drive.
When we picked up the trailer, it looked smaller than it had when we first went to see it. We thought this would leave half of our stuff behind. But playing Tetris as a child and as a procrastinating PhD student paid off. (True story: I used to play the Tetris built into Emacs, and I didn't know it tracked the highest score across the whole department until my friends congratulated me for topping it.) Well, thanks to all that training, we got everything in.
Best Laid Plans, Meet Cat
My plan for the roadtrip was to cross toward southwest coming from the north (I-90, I-70, I-44, and I-40), and finally driving back up to the Bay Area. This was a trailer friendly route that didn't cross high mountains.
It was more than 45 hours of driving. With a trailer you go slow. And since the trailer burns a lot of gas, you stop for fuel almost twice as often. We planned to leave on July 1st, and visit our friends at Kenyon College on the first day, so that first day was only a half day. Then Springfield, Missouri, then Amarillo, Texas, then Williams, Arizona, then a Grand Canyon visit, then Las Vegas, and finally the Bay Area.
Of course, we didn't book the hotels in advance. We would book each one on the day of travel from the phone, using Hotwire or the hotel sites.
Perfect plan, right?
On the morning of July 1st, we were doing the final cleanup and walkthrough prep on the house we had sold, and we let our cat Pasha out as usual. He rarely strayed far from the house and was always back soon. But the poor cat had been stressed for two weeks watching our furniture disappear. Every time a chair vanished, Pasha would inspect the empty void and glare at me as if to say, "You fools, what have you done to my house?" He must have been furious, because when we finished up with the final prep at the empty house, he was nowhere to be seen. We were supposed to leave at noon for our half-day first drive. Instead I spent the entire afternoon roaming the neighborhood like a deranged madman, calling his name and shaking his favorite snacks. It was brutally hot, and I got sunburned looking for him. I looked like a lobster... again.
Pasha didn't come back until 11:00 PM. We had to stay another night in Buffalo. At this point, my panic was real. I thought we were trapped forever in Buffalo's gravity well.
The next morning, after breakfast with friends in Buffalo, we finally got on our way, Pasha curled up in my daughters' laps. After all that buildup, leaving Buffalo felt anticlimactic.
The drive was nice and boring for the most part. Driving with a trailer is not hard, but backing up is very tricky. So I parked accordingly at the hotels and service stations. Not fun.
Another thing that wore on me was the state of the American highways. Some stretches looked like freshly bombarded potato fields. Missouri was the worst. You hit a crater, your spine compresses, you worry about your tire rims, and a full second later, the 5000-pound trailer hitched to your bumper hits the exact same hole with even a louder bang. The government seems to always find money for overseas misventures, but fails to fix the roads that millions of Americans drive on every day.
I listened to the Science of Discworld books while driving, which kept me occupied. But it was hard to do anything with the cat along. When he attempted another escape at lunch on day 2, we scratched the Grand Canyon and Las Vegas plans and just drove. My daughters were very cooperative with our crazy plan. As long as they had the phones to keep them busy, they didn't mind the drive. They even managed to keep Pasha soothed during the trip.
We traveled through the heatwave in the first week of July. More than 100F in Arizona, 95F in California almost the whole way, but the Bay Area still showed 75F? What is this black magic?
Landed, Still Partly Unpacked
Well, we did it. In one piece (well, two, if you count the trailer), and it has been a week now. We are still unpacking and buying new furniture.
The move itself was exhausting, and adjusting to a new place turns out to be its own kind of work. A lot of little things are different. For example, why are there no bottle redemption centers inside the supermarkets in the Bay Area? Where are we supposed to recycle the bottles? And what are these tiny microscopic ants coming into the house, and how do I stop them?
OK, let's not dwell on these. Good weather. A lot of CS and AI action here. Please suggest good meetups, activities, and places to see around the Bay Area.
Supabase Pipelines is now in Public Alpha
Supabase Pipelines is now in public alpha with schema change support, a faster initial copy, and a new destination request form for ClickHouse, Snowflake, and DuckLake.
Inside MySQL 9.7 LTS Features
MySQL 9.7, a Long-Term Support (LTS) release, incorporates a variety of potential features spanning across multiple technical domains. This article covers some of the primary features introduced and evaluates their practical utility within the MySQL database environment. Following the End-of-Life (EOL) status of MySQL 8.0, this subsequent LTS release is designed to provide enhanced stability … Continued
The post Inside MySQL 9.7 LTS Features appeared first on Percona.
Making 768 servers look like 1
How to make 768 distinct Postgres servers look like 1 to your applications.
July 13, 2026
Rebuild large indexes on Aurora PostgreSQL with Blue/Green Deployments
In this post, we show how to rebuild large indexes on Amazon Aurora PostgreSQL by combining Amazon Aurora Blue/Green Deployments with Aurora Optimized Reads. By performing the reindex on the green (staging) environment with a Non-Volatile Memory express (NVMe)-backed instance class, the sort phase uses fast local storage instead of Amazon EBS over the network, and you avoid impacting production workloads.
MyDumper Locking Mechanisms Revisited: Introducing SAFE_NO_LOCK
About a year ago, we discussed how MyDumper refactored its locking mechanisms to move away from old, rigid flags and transitioned towards more flexible, streamlined execution. Since then, the MyDumper community hasn’t stood still. In recent releases, the locking architecture was further standardized under a single overarching option: --sync-thread-lock-mode. Along with this modernization came a … Continued
The post MyDumper Locking Mechanisms Revisited: Introducing SAFE_NO_LOCK appeared first on Percona.
When the Postgres query planner goes rogue
How PlanetScale Database Traffic Control contained a runaway Postgres query after the planner abandoned an index.
July 10, 2026
PostgreSQL as a converged database with pglayers-full
PostgreSQL is extensible, allowing it to serve as a multi-model or converged database with built-in data types and indexes. If you're interested in exploring its features, compiling and installing all extensions can be quite a bit of work, but having an image packed with extensions makes things much easier. For this, I recommend using https://pglayers.github.io/ (thanks to Ismael Mejía).
Start pglayers-full in Docker
I began by using the ghcr.io/pglayers/pglayers-full:17 image to start the container. Not only did I get all the extensions installed, but it also ships the MongoDB-compatible endpoint offered by DocumentDB:
# remove previous container with same name ⚠️
docker rm -f pg-documentdb
# install DocumentDB extension before it can open the MongoDB-compatible endpoint
echo 'CREATE EXTENSION IF NOT EXISTS documentdb_core CASCADE;
CREATE EXTENSION IF NOT EXISTS documentdb CASCADE;' > /tmp/01-documentdb.sql
# start the container, exposes the PostgreSQL and MongoDB-compatible ports n host, set
docker run -d --name pg-documentdb \
-p 5432:5432 -p 10260:10260 \
-e POSTGRES_PASSWORD=xxxMongoDBxxx\
-v /tmp/01-documentdb.sql:/docker-entrypoint-initdb.d/01-documentdb.sql:ro \
ghcr.io/pglayers/pglayers-full:17 \
-c max_worker_processes=64 \
-c max_connections=200 \
-c documentdb.pg_gw_username=postgres \
-c documentdb.pg_gw_password=xxxMongoDBxxx\
-c cron.database_name=postgres
I waited for the PostgreSQL endpoint to be up:
echo -n "Waiting to get PostgreSQL endpoint up on 5432"
until docker exec pg-documentdb pg_isready -p 5432 2>/dev/null |
grep "5432 - accepting connections"
do echo -n . ; sleep 1 ; done
I listed the available extensions:
docker exec -i pg-documentdb psql -U postgres -t -c "select 'Available extensions: '||string_agg(name,', ') from pg_available_extensions;"
I could already connect to the PostgreSQL endpoint and use those extensions. As I also wanted to use the MongoDB-compatible API, I downloaded the MongoDB image that contains the client (MongoSH):
docker pull mongo
I waited for the MongoDB endpoint to be up:
echo -n "Waiting to get MongoDB emulation up on 10260"
until docker logs pg-documentdb 2>/dev/null |
grep "bound to port 10260"
do echo -n . ; sleep 1 ; done
echo "Ready."
I can connect with MongoSH simply by linking the PostgreSQL container when starting the MongoDB client:
docker run -it --rm --link pg-documentdb:pg mongo \
mongosh "mongodb://postgres:xxxMongoDBxxx@pg:10260/?tls=true&tlsAllowInvalidCertificates=true"
Now I define aliases to connect to PostgreSQL via the two endpoints, with psql and mongosh:
alias p='docker exec -it pg-documentdb psql -U postgres'
alias m='docker run --rm -it --link pg-documentdb:pg mongo mongosh "mongodb://postgres:xxxMongoDBxxx@pg:10260/?tls=true&tlsInsecure=true"'
Ready to explore all extensions. I'll go further with DocumentDB.
Import MongoDB Sample Dataset to PostgreSQL DocumentDB
I tested with some data using the MongoDB client image to access the Sample Dataset and imported it into PostgreSQL via the DocumentDB endpoint with mongoimport:
# ⬇️ using --link to quickly connect to the other container
docker run --rm -i --link pg-documentdb:pg mongo bash <<'SH'
# get wget
apt update -qqy
apt install wget -qy
# get sample data
wget -q -c https://atlas-education.s3.amazonaws.com/sampledata.archive
# restore sample data
mongorestore -j 5 --drop --uri "mongodb://postgres:xxxMongoDBxxx@pg:10260/?tls=true&tlsInsecure=true" --archive=sampledata.archive
# create the index that failed because of "textIndexVersion": 3
mongosh "mongodb://postgres:xxxMongoDBxxx@pg:10260/sample_mflix?tls=true&tlsInsecure=true" --eval '
SH
...
One index creation failed because it sets textIndexVersion 2. No worries, we will create the same index later, just without mentioning the version, which is specific to vanilla MongoDB.
Look at MongoDB-compatible and DocumentDB execution plans
I can connect to the MongoDB API, create a text index on the movies collection, and execute a query just like I would in MongoDB. I used the m alias defined above, but you can connect with any MongoDB client.
Current Mongosh Log ID: 6a50e7576d644ce7f3c3a7d7
Connecting to: mongodb://<credentials>@pg:10260/?tls=true&tlsInsecure=true&directConnection=true&appName=mongosh+2.9.2
Using MongoDB: 7.0.0
Using Mongosh: 2.9.2
For mongosh info see: https://www.mongodb.com/docs/mongodb-shell/
To help improve our products, anonymous usage data is collected and sent to MongoDB periodically (https://www.mongodb.com/legal/privacy-policy).
You can opt-out by running the disableTelemetry() command.
[direct: mongos] test> disableTelemetry()
Telemetry is now disabled.
[direct: mongos] test> use sample_mflix;
switched to db sample_mflix
[direct: mongos] sample_mflix> show collections
comments
embedded_movies
movies
sessions
theaters
users
[direct: mongos] sample_mflix> db.movies.createIndex({
"cast": "text",
"fullplot": "text",
"genres": "text",
"title": "text"
}, {
"name": "cast_text_fullplot_text_genres_text_title_text",
"weights": { "cast": 1, "fullplot": 1, "genres": 1, "title": 1 },
"default_language": "english",
"language_override": "language"
}
)
cast_text_fullplot_text_genres_text_title_text
[direct: mongos] sample_mflix> db.movies.find(
{
$text: {
$search: "\"star wars\""
}
}
).explain("executionStats").executionStats
;
{
nReturned: Long('13'),
executionTimeMillis: 137.596,
executionStartAtTimeMillis: 135.295,
totalDocsExamined: Long('13'),
totalKeysExamined: Long('13'),
executionStages: {
stage: 'FETCH',
nReturned: Long('13'),
executionTimeMillis: 137.596,
executionStartAtTimeMillis: 135.295,
totalDocsExamined: 13,
totalKeysExamined: 13,
numBlocksFromCache: 73,
inputStage: {
stage: 'FETCH',
nReturned: Long('13'),
executionTimeMillis: 137.57,
executionStartAtTimeMillis: 135.292,
totalDocsExamined: 13,
totalKeysExamined: 13,
exactBlocksRead: 12,
numBlocksFromCache: 73,
inputStage: {
stage: 'IXSCAN',
nReturned: Long('13'),
executionTimeMillis: 0.831,
executionStartAtTimeMillis: 0.831,
indexName: 'cast_text_fullplot_text_genres_text_title_text',
totalKeysExamined: 13,
numBlocksFromCache: 10
}
}
}
}
I've shown the execution plan to verify that the MongoDB-compatible text index was utilized. I can also switch to the SQL API, using the p alias defined above, and run the same query to view the PostgreSQL execution plan for it:
psql (17.10 (Debian 17.10-1.pgdg13+1))
Type "help" for help.
postgres=# \pset pager off
postgres=# EXPLAIN (ANALYZE, BUFFERS, VERBOSE, COSTS OFF)
SELECT document FROM documentdb_api_catalog.bson_aggregation_find(
'sample_mflix',
'{
"find":"movies",
"filter":{
"$text":{
"$search":"\"star wars\""
}
}
}'::documentdb_core.bson
);
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Custom Scan (DocumentDBApiQueryScan) (actual time=36.533..38.597 rows=13 loops=1)
Output: document
Buffers: shared hit=34
-> Bitmap Heap Scan on documentdb_data.documents_112 collection (actual time=36.530..38.587 rows=13 loops=1)
Output: document
Filter: documentdb_api_internal.bson_text_meta_qual(collection.document, '''star'' <-> ''war'''::tsquery, '\x0400000000000000ffffffff000000000000000000000000000000007b0000002c0000007f000000040000000000803f000000000000803f000000000000803f000000000000803f000000000400000063617374000800000066756c6c706c6f74000600000067656e72657300050000007469746c6500b83300006c616e677561676500'::bytea, true)
Heap Blocks: exact=12
Buffers: shared hit=34
-> Bitmap Index Scan on cast_text_fullplot_text_genres_text_title_text (actual time=1.208..1.209 rows=13 loops=1)
Index Cond: (collection.document OPERATOR(documentdb_api_catalog.@#%) '''star'' <-> ''war'''::tsquery)
Buffers: shared hit=10
Planning:
Buffers: shared hit=1
Planning Time: 0.340 ms
Execution Time: 39.203 ms
(15 rows)
postgres=# \d documentdb_data.documents_112
Table "documentdb_data.documents_112"
Column | Type | Collation | Nullable | Default
-----------------+----------------------+-----------+----------+---------
shard_key_value | bigint | | not null |
object_id | documentdb_core.bson | | not null |
document | documentdb_core.bson | | not null |
Indexes:
"collection_pk_112" PRIMARY KEY, btree (shard_key_value, object_id)
"documents_rum_index_152" documentdb_rum (document documentdb_api_catalog.bson_rum_text_path_ops (weights='{ "cast" : 1.0, "fullplot" : 1.0, "genres" : 1.0, "title" : 1.0 }', defaultlanguage=english, languageoverride=language))
Check constraints:
"shard_key_value_check" CHECK (shard_key_value = '112'::bigint)
Both execution plans indicate that the text index was used to directly retrieve 13 keys (totalKeysExamined: 13 in the MongoDB-compatible plan and rows=13 in the PostgreSQL plan) from 10 index pages (numBlocksFromCache: 10, Buffers: shared hit=10) and then fetch the corresponding documents for the results.
The MongoDB text index is implemented in PostgreSQL as a RUM index through the DocumentDB extension. This highlights PostgreSQL’s robust open-source ecosystem and community. Vanilla PostgreSQL offers a permissive license and supports extensions for additional data types, such as BSON. PostgresPro improved text search with RUM indexes that include scoring. Microsoft also added support for BSON text search with RUM. Ismael developed Docker images containing all necessary extensions. As a result, we can now easily connect and utilize this unified multi-model database.
The experimentation is limitless. With this pglayers-full image, you can use plenty of extensions (some were already enabled by DocumentDB):
postgres=# CREATE EXTENSION IF NOT EXISTS documentdb;
NOTICE: extension "documentdb" already exists, skipping
CREATE EXTENSION
postgres=# CREATE EXTENSION IF NOT EXISTS vector;
NOTICE: extension "vector" already exists, skipping
CREATE EXTENSION
postgres=# CREATE EXTENSION IF NOT EXISTS postgis;
NOTICE: extension "postgis" already exists, skipping
CREATE EXTENSION
postgres=# CREATE EXTENSION IF NOT EXISTS timescaledb;
ERROR: function "time_bucket" already exists with same argument types
postgres=# CREATE EXTENSION IF NOT EXISTS pg_textsearch;
CREATE EXTENSION
postgres=#
postgres=# CREATE EXTENSION IF NOT EXISTS pg_graphql;
CREATE EXTENSION
postgres=# CREATE EXTENSION IF NOT EXISTS orafce;
CREATE EXTENSION
postgres=# CREATE EXTENSION IF NOT EXISTS pg_duckdb;
CREATE EXTENSION
I selected DocumentDB for this demonstration because it offers numerous advantages as a document database. The DocumentDB extension for PostgreSQL provides a fully open-source solution for MongoDB applications—both the MongoDB client and PostgreSQL server are OSS, as is the DocumentDB extension, which is part of the Linux Foundation. Although other converged databases and MongoDB emulations exist, they often lack the same level of freedom and features. For example, the index shown here, which combines document and full-text search capabilities, isn't supported in Oracle's MongoDB emulation:
I haven't selected a particular case here. I just created the index from the Sample Dataset provided by MongoDB's beginner courses.
Next time you hear about multi-model, converged databases, or native APIs, remember that PostgreSQL was built by Michael Stonebraker before those marketing labels (THE DESIGN OF POSTGRES - 1986). It was specifically designed to take a relational foundation and make it extensible enough to natively support complex objects and abstract data types. Over time, SQL databases experimented with ORDBMS, and NoSQL databases promoted multi-model approaches, which became quite popular. RDBMS vendors responded by adding different API layers on top of their SQL schemas, calling it converged. Meanwhile, the PostgreSQL ecosystem continued to innovate by integrating native data types and access methods through its very flexible, extensible architecture. This extension framework allows developers to plug in new data types and index types as native extensions rather than transformations in the query layer. It's highly compatible with Docker image layers, and projects like pglayers.github.io use it to improve the developer experience.
Running DuckDB as a MySQL 9.7 storage engine
ducksdb-mysql-engine is an experimental build of MySQL 9.7 where a table you mark ENGINE=DuckDB answers analytical queries from DuckDB instead of InnoDB. Same server, same connection, no second copy of the data. On TPC-H at scale factor 10, InnoDB times out on 6 of the 22 queries and burns 1317 seconds on the 16 it … Continued
The post Running DuckDB as a MySQL 9.7 storage engine appeared first on Percona.