-
Step by Step: ProxySQL HA with BGP ECMP Anycast
In our previous blog post ProxySQL HA with BGP ECMP Anycast, we established why we would want to use BGP ECMP as a strategy for making our ProxySQL cluster highly available. Now let’s look at how to implement it technically.
For this scenario we assume that we have:
an OPNsense instance as our BGP Router with the IP address 10.5.8.251
Two ProxySQL nodes (proxysql-01 with IP 10.5.20.4 and proxysql-02 with IP 10.5.20.5)
10.5.200.1 as the anycast IP we want both ProxySQL nodes to accept connections on
Setup on the router
Enable BGP on OPNsense
The out-of-the-box installation of OPNsense does not come with BGP support. To add it, install the FRRouting package first (os-frr), which will enable available protocols for dynamic routing.
Install the os-frr plugin in System -> Firmware -> Plugins.
We need to activate the routing service on our OPNsense host.
In Routing -> General check “enable”
Next, assign an Autonomous System (AS) number to the OPNsense BGP peer.
An AS number identifies a network, or a group of routers, under a single administrative domain.
Choose a private AS number from the range 64512-65534.
In Routing -> BGP (advanced mode):
check “enable”.
set the chosen AS number (in this example we use 64512).
set Maximum Paths to 2 to match the number of ProxySQL nodes that we have.
Maximum Paths configures OPNsense to perform Equal-Cost Multi-Path (ECMP) load balancing across the two paths.
Any additional paths are kept as backups and only used if an active route is withdrawn.
Create a firewall rule for BGP traffic
BGP exchanges routing information through a TCP connection on port 179.
Our ProxySQL nodes will establish this connection towards OPNsense, so we need a firewall rule to allow this traffic.
First, we will create an alias for the ProxySQL nodes. This keeps the firewall rule readable, and new nodes only need to be added in one place.
In Firewall -> Aliases, add:
Name: proxysql_nodes
Type: Host(s)
Content: 10.5.20.4, 10.5.20.5 (The IP addresses of our ProxySQL nodes)
With the Alias in place, we can now continue to define the actual Firewall rule:
Navigate to Firewall -> Rules and create a new rule:
Description: Allow ProxySQL network to BGP peer with OPNsense
Interface: Select the interface the ProxySQL nodes are in.
Action: Pass
Direction: in
Version: IPv4
Protocol: TCP
Source: proxysql_nodes (the alias we created in the previous step)
Source port: any
Destination: the OPNsense address the ProxySQL nodes peer with (10.5.8.251)
Destination port: BGP (179)
Note, here we do not explicitly enable logging. It may be helpful to enable logging that if you need to debug the BGP peering.
Set up route filtering with a prefix list
We need to set up an inbound filter using a prefix list.
The prefix list defines the networks that OPNsense will accept routes for, and should be as narrow as possible to prevent a misbehaving peer from advertising routes that could re-route sensitive traffic through it.
Prefix lists are configured in Routing -> BGP -> Prefix Lists.
Create the prefix list:
Description: ProxySQL Anycast IP
Name: ANYCAST-PROXYSQL-IN
IP Version: IPV4
Sequence Number: for this example we use 10. Sequence numbers are used in order to set the order with which to apply the rules, in case you would have multiple rules for the same prefix list. We only need to create one entry for the ProxySQL Anycast IP.
Action: Permit, as we want to allow the ProxySQL Anycast IP.
Network: 10.5.200.1/32, the Anycast IP of our ProxySQL nodes.
Tip: Click the ⓘ icon next to a field in the OPNsense UI for more information.
Configure BGP neighbors
In this step we will configure OPNsense to know about our ProxySQL servers and their intent to peer.
Neighbor configuration defines which IPs are allowed to speak the BGP protocol with OPNsense. In our case, we need to define a neighbor for both of our ProxySQL hosts:
Choose a unique AS number for the cluster. All ProxySQL nodes belonging to this cluster will share this AS number, whilst separate clusters must use different, dedicated AS numbers.
Ensure that the cluster AS number is distinct from the one configured for OPNsense.
For this example we choose the AS number 64513.
Navigate to Routing -> BGP -> Neighbors and add a new one.
Description: ProxySQL-01
Peer-IP: 10.5.20.4
Remote AS: 64513
Local AS: 64512
Prefix-List In: ANYCAST-PROXYSQL-IN:10
Make sure you repeat this for the second ProxySQL.
All configurable BGP options can be found in the OPNsense documentation.
Setup on the ProxySQL nodes
Next, assign the anycast virtual IP (10.5.200.1) to the loopback interface of each ProxySQL node, so that the node accepts traffic intended for that IP address.
bash
Copy
Copied!
# Add the Anycast VIP to the loopback interface
sudo ip addr add 10.5.200.1/32 dev lo
Make the address persistent across reboots by adding it to netplan, systemd-networkd or /etc/network/interfaces.
Install ExaBGP
ExaBGP is a tool that can speak the BGP protocol with OPNsense and is able to announce / withdraw routes.
Install ExaBGP on the ProxySQL hosts with:
bash
Copy
Copied!
sudo apt-get update
sudo apt-get install exabgp
For information on installing ExaBGP on other distributions, you can check the ExaBGP wiki here.
Note that BIRD (BIRD Internet Routing Daemon) or FRR can be used as alternative tools to ExaBGP, but in this example we will go with ExaBGP.
Create the health check
As we only want to route traffic to a ProxySQL host when the ProxySQL process is running, we need a way to tell ExaBGP when to announce the route and when to withdraw it.
We will write a health check script that ExaBGP can execute to determine the state of our ProxySQL process.
If this health check fails, ExaBGP withdraws the node’s route from OPNsense. OPNsense removes that node as an anycast next hop, and routes the traffic to the remaining healthy nodes.
In our example, we will use a simple bash script that uses mysqladmin to send a PING to ProxySQL:
bash
Copy
Copied!
#!/usr/bin/env bash
ANYCAST_IP="10.5.200.1/32"
FAILED=1
while true; do
# Execute the health check command and depending on the return code
# announce or withdraw the route.
mysqladmin --defaults-extra-file=/etc/exabgp/proxysql-monitor.cnf --connect-timeout=2 ping &> /dev/null
STATUS=$?
if [ $STATUS -eq 0 ]; then
if [ $FAILED -ne 0 ]; then
# Recovered: Announce route
echo "announce route $ANYCAST_IP next-hop self"
FAILED=0
fi
else
if [ $FAILED -eq 0 ]; then
# Health check failed: Withdraw route
echo "withdraw route $ANYCAST_IP next-hop self"
FAILED=1
fi
fi
sleep 2
done
Save the health check file as /etc/exabgp/healthcheck-proxysql, and make it executable with chmod +x /etc/exabgp/healthcheck-proxysql.
To avoid passwords in the check script, we tell mysqladmin to load them from a separate file. Create that file (/etc/exabgp/proxysql-monitor.cnf) with the credentials that you want the check to use to connect to ProxySQL:
bash
Copy
Copied!
[client]
user=user
password=password
host=127.0.0.1
port=6033
Ensure that you replace “user” and “password” with your actual user credentials. Restrict the file permissions with:
bash
Copy
Copied!
sudo chown exabgp:exabgp /etc/exabgp/proxysql-monitor.cnf
sudo chmod 600 /etc/exabgp/proxysql-monitor.cnf
In our example, the script only checks if connecting to ProxySQL succeeds, and not whether ProxySQL can reach any backend servers.
The checks you come up with should ideally only test the readiness of the ProxySQL process, regardless of the health of the MySQL nodes behind it. Otherwise you might get unwanted side effects. For example:
you could write a check to verify whether there are hosts with status ONLINE in the runtime_mysql_servers table. At first it might sound like a good idea, as a misconfigured ProxySQL server would be taken offline.
BUT: In case your MySQL cluster is experiencing a downtime, ALL ProxySQLs will withdraw their routes, causing clients to see timeouts instead of potentially helpful error messages. Define your health checks carefully based on your specific architecture.
Configuring ExaBGP
ExaBGP configuration lives in the /etc/exabgp/exabgp.conf file. You can find full details on what can be configured there in the ExaBGP documentation.
For the purpose of this blog post, we will define three blocks.
The process block defines the path to the health check script.
The template block defines the BGP settings and which health check process to run.
Each neighbor block defines the router we want ExaBGP to peer with.
bash
Copy
Copied!
# -------------------------------------------------------------------
# Process Definitions
# -------------------------------------------------------------------
process proxysql-healthcheck {
run "/etc/exabgp/healthcheck-proxysql";
encoder text;
}
# -------------------------------------------------------------------
# Neighbor Templates
# -------------------------------------------------------------------
template {
neighbor opnsense-nodes {
router-id 10.5.20.4;
local-as 64513;
peer-as 64512;
api {
processes [ proxysql-healthcheck ];
}
}
}
# -------------------------------------------------------------------
# OPNsense nodes
# -------------------------------------------------------------------
neighbor 10.5.8.251 {
inherit opnsense-nodes;
local-address 10.5.20.4;
}
Create the file on proxysql-01 and proxysql-02, but make sure to update the neighbor and template block. The router-id and local-address should be set to 10.5.20.5 on proxysql-02.
Once you have created this file, restart ExaBGP.
bash
Copy
Copied!
systemctl restart exabgp
You can check the status of ExaBGP by running exabgpcli show neighbor summary on the ProxySQL hosts.
An overview of the workflow for a healthy ProxySQL node
ExaBGP starts the health check script that we configured in exabgp.conf
The script sees that ProxySQL is running, and outputs announce route 10.5.200.1/32 next-hop self.
ExaBGP receives this output and sends a BGP UPDATE message to OPNsense.
OPNsense adds the ProxySQL node as potential “next hop” to its routing table for 10.5.200.1.
If the health checks detects that ProxySQL is not running, it will output withdraw route 10.5.200.1/32 next-hop self, which tells ExaBGP to send a BGP update for OPNsense to remove that route from its routing table.
The traffic is redistributed to the remaining healthy ProxySQL node.
Check BGP ECMP is configured correctly
Check the firewall
Ensure that the firewall is not blocking traffic by navigating to Firewall -> Log Files -> Live View. Make sure you have enabled logging in the firewall rule you created.
Filter for “address” “is” “10.5.200.1” and check that the connections are not blocked.
Check ExaBGP on the ProxySQL
Run the health check on the ProxySQL to confirm that the ProxySQL reports that it is healthy, and announces the route.
bash
Copy
Copied!
sudo -u exabgp /etc/exabgp/healthcheck-proxysql
You should see output like:
bash
Copy
Copied!
announce route 10.5.200.1/32 next-hop self
Check that ExaBGP announces the route with:
bash
Copy
Copied!
exabgpcli show adj-rib out
You should see output like:
bash
Copy
Copied!
neighbor 10.5.8.251 ipv4 unicast 10.5.200.1/32 next-hop self
Check that ExaBGP has an established BGP session to OPNsense with:
bash
Copy
Copied!
exabgpcli show neighbor summary
You want to see that the state is established. State active means “ready to connect”, but no connection is actually made.
bash
Copy
Copied!
Peer AS up/down state | #sent #recvd
10.5.8.251 64512 0:00:57 established 2 6
Verify the BGP connections and routes on OPNsense.
Navigate to Routing -> Diagnostics -> BGP to check the routing status.
The Anycast IP should appear twice, one entry for each ProxySQL. Both entries should be marked valid.
The path should show the AS number 64513.
BGP always selects a single best path. With Maximum Paths set, the other equal-cost paths are also installed in the routing table and are flagged as multipath.
You can also run vtysh on the OPNsense CLI to check this:
bash
Copy
Copied!
vtysh -c "show ip route 10.5.200.1/32"
You should see an entry like:
bash
Copy
Copied!
Routing entry for 10.5.200.1/32
Known via "bgp", distance 20, metric 0, best
Last update 00:05:12 ago
Flags: Selected
Status: Installed
* 10.5.20.4, via vtnet1, weight 1
* 10.5.20.5, via vtnet1, weight 1
The * next to each result shows that this is an active next-hop path.
Because the two results share the same weight (1), ECMP is active, and OPNsense will load balance the tcp connections equally across the two routes.
Summary
In this blog post we stepped through an example setup of BGP ECMP Anycast for ProxySQL. We configured OPNsense to accept anycast routes from our ProxySQL nodes and load-balance across them. On each node, ExaBGP announces the route whilst ProxySQL is healthy and withdraws the route when ProxySQL fails. To scale the cluster, add the new node to the proxysql_nodes alias, create a BGP neighbor for it, and raise Maximum Paths to match the new node count.
This post is part of the Percona Community Writers Program.
-
Making Sense of MySQL Telemetry Metrics
In the first post in this series, we configured MySQL Telemetry to export OpenTelemetry metrics to Prometheus. Once the metrics arrive, the more important question is how a DBA should read them. This post is not a catalogue of every metric or meter. Its purpose is to build a practical way of thinking: start with […]
-
Why MySQL Bug Fixes Can Differ Across LTS Releases
At a recent discussion with MySQL ACEs and Rockstars, we were asked a fair question: If a bug is fixed in one supported MySQL LTS series, why isn’t it always fixed in another? A quick refresher: LTS means Long-Term Support. Within an LTS series, MySQL aims to keep the feature set and data format stable […]
-
DBTrail: Analytical Reports on Your MySQL Data, Without Running Them on MySQL – Part 1
MySQL is very good at serving application workloads, but things get more complicated when somebody decides to run a large report on the same server.
A scan can push hot pages out of the buffer pool. A long-running read can hold back purge. A GROUP BY over millions of rows can start writing temporary tables to disk.
The traditional answer is a reporting replica. But that means running another MySQL server, and at the end of the day it is still a row-oriented database.
Another option is moving the data into an analytical database. That can work very well, but now you have a data pipeline to build, operate, monitor, and eventually debug.
We have been looking at what MySQL users can do with DuckDB, and DBTrail is an interesting approach.
DBTrail is open source under Apache 2.0. It is being built by Daniel Guzman-Burgos, who previously worked at Percona as a MySQL Technical Lead.
The basic idea is simple.
DBTrail connects to MySQL similarly to a replica. It makes an initial copy of the tables using mydumper and stores the data as Parquet files, either locally or in S3.
After that, it reads the MySQL binary log and periodically applies changes to the copy.
You query the resulting data with DuckDB.
Nothing is installed inside MySQL, there is no MySQL plugin, agent, or trigger.
The setup would look like this:
Let’s do some performance testing.
The setup
We used three AWS machines in the same subnet in us-west-2a.
Role
Machine
Software
Source
r7i.4xlarge
Percona Server for MySQL 8.4.11-11
DBTrail and DuckDB
r7i.4xlarge
DBTrail 0.99.0, DuckDB 1.5.6
Load generator
c7i.2xlarge
sysbench 1.0.20, sysbench-tpcc
Machines in more detail
Source and DBTrail machines
Load machine
CPU
Intel Xeon Platinum 8488C, 8 cores, 16 threads
Same CPU, 4 cores, 8 threads
Memory
128 GB, 123.8 GB usable
16 GB
Disk
EBS gp3, 400 GB, 16,000 IOPS, 1,000 MB/s provisioned
Not used by the test
Filesystem
ext4, relatime,discard,commit=30
I/O scheduler
none, 128 KB read-ahead
OS
Ubuntu 24.04.5, kernel 7.0.0-1013-aws
Same
Kernel settings
swappiness 60, dirty ratio 20/10, THP madvise
Same
Docker
29.1.3
The MySQL source
Percona Server runs in Docker using host networking.
We used full durability and a buffer pool large enough to keep the whole data set in memory:<code>innodb_buffer_pool_size = 96G
innodb_redo_log_capacity = 32G
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
innodb_flush_method = O_DIRECT
innodb_io_capacity = 8000
innodb_io_capacity_max = 16000
binlog_format = ROW
binlog_row_image = FULL
gtid_mode = ON</code>The workload is sysbench-tpcc with 200 warehouses, which produces 102 million rows and about 19 GB of data when the run started.
For the initial workload we held the workload at 300 transactions per second.
One TPC-C transaction in this test is roughly 28 SQL statements, so that means about:
8,500 QPS
5,200 row changes per second
It is important to put that load into context—on the same server flat out with 64 threads and nothing else attached, it reached 4,049 transactions per second, or about 115,000 QPS.
So the 300 TPS test uses only about 7% of the available capacity, and we chose a relatively light load intentionally. We wanted to see what analytical queries cost even when the source has plenty of headroom.
DBTrail
DBTrail installs with one command that starts its Docker Compose stack:<code>curl -fsSL https://raw.githubusercontent.com/dbtrail/dbtrail/v0.99.0/install.sh \
| DBTRAIL_REF=v0.99.0 sh</code>The stack contains two containers: DBTrail itself and a MySQL 8.4.9 instance DBTrail uses as an index of row changes.
This internal MySQL needs attention, as the default installation leaves its buffer pool at MySQL’s 128 MB default. For this workload, that is nowhere near enough.
For the main tests we configured it like this:<code>innodb_buffer_pool_size = 48G
innodb_redo_log_capacity = 16G
innodb_log_buffer_size = 256M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_io_capacity = 8000
innodb_io_capacity_max = 16000
innodb_page_cleaners = 16
innodb_flush_neighbors = 0
skip-log-bin</code>DuckDB ran on the same machine with its defaults: 16 threads and a 99 GB memory limit.
Does DBTrail slow MySQL down?
Short answer: at this workload, almost not at all.
The load ran continuously. Each row below represents one phase of the same test.
Phase
TPS
QPS
Median 95th percentile
Worst second
Nothing attached, 10 min
299.9
8,554
41.9 ms
46.6 ms
DBTrail reading binlog, 10 min
300.5
8,535
41.9 ms
47.5 ms
Initial copy of all tables, 4m 40s
298.1
8,460
41.1 ms
118.9 ms
Copy updated every 5 min, 75 min
300.2
8,539
41.1 ms
46.6 ms
There is one spike here that stands out.
When the initial copy started, at approximately second 1,500 of the workload, the 95th percentile latency jumped to 119 ms and throughput dropped to 271 transactions for that second and it happened once.
The initial copy takes a global read lock briefly when it starts, and the timing matches that operation, after that, DBTrail read 102 million rows in less than five minutes without any measurable slowdown in the application workload.
CPU usage confirms the same story: the source normally sat around 18% CPU, but during the initial table copy it increased to about 35%.
When we later ran the five analytical reports directly against MySQL, CPU was around 24%.
There is also a noticeable increase in source writes around minute 12. That happened three minutes before DBTrail connected, so it was unrelated to DBTrail.
The DBTrail machine itself writes roughly as much as the source because it keeps an index of every captured row change.
Query times on the TPC-C data
DBTrail creates a views.sql file containing a DuckDB view for each source table.
From there you can query the data normally:<code>$ duckdb -init views.sql
D SELECT
i.i_id,
i.i_name,
sum(ol.ol_quantity) AS units,
sum(ol.ol_amount) AS revenue
FROM tpcc.order_line1 ol
JOIN tpcc.item1 i ON i.i_id = ol.ol_i_id
GROUP BY i.i_id, i.i_name
ORDER BY revenue DESC
LIMIT 10;</code>We ran the same five reports against MySQL and against DuckDB while the transactional workload continued running, during the workload the data had grown from 102 million to 113 million rows.
MySQL had essentially everything cached in memory and the DBTrail copy was also in its normal operating state: a base Parquet file plus the accumulated change files that DuckDB needs to combine when executing the query.
The results:
Report
MySQL
DuckDB on DBTrail copy
Revenue per warehouse
9.7 s
0.75 s
Orders and revenue per district/month
46.5 s
2.8 s
Ten best-selling items
5m 32s
1.7 s
Customers by state and credit
3.6 s
0.18 s
Warehouses low on stock
3.0 s
0.23 s
Total
6m 35s
5.7 s
This is where the difference becomes interesting: 6m 35s on MySQL and less than 6s on DuckDB.
Running TPC-H: all 22 queries
TPC-H is a more standard analytical workload; for this test, we loaded TPC-H at scale factor 10.
The dataset contained:
86.6 million rows
18.2 GB of InnoDB data
Normal indexes on join keys, order dates, and ship dates
The initial DBTrail copy took 6 minutes 26 seconds and produced 2.8 GB of Parquet files.
We ran the same SQL against both systems and compared results:
MySQL
DuckDB warm
All 22 queries
5m 24s
10.3 s
MySQL wins Q19 because an index can go directly to the relevant rows, Q17 is effectively a tie and for the rest, DuckDB is substantially faster.
If you are interested in these performance numbers, stay tuned for Part 2, where we will look into how often DBTrail refreshes data to stay up to date.
The post DBTrail: Analytical Reports on Your MySQL Data, Without Running Them on MySQL – Part 1 appeared first on Percona.
-
Village News: MySQL News + Events (6 October 2026)
Welcome back to Village News, our curated roundup of MySQL and database news.
If you want to get these updates, just subscribe to the blog.
Enjoy!
MySQL News
Note: Aggregated MySQL news can be found at Planet for MySQL Community and Planet MySQL (Oracle curated)
Thread Pool in Percona Server and MySQL (Part 1)
Percona Blog
TL;DR - MySQL 26.7.0 and 9.7.2 bring a thread pool to Community Server for the first time.
TidesDB now available for MySQL v9, v26
Alex Gaetano Padula, TidesDB Blog
TL;DR - TideSQL-MySQL 2.0.0 loads the TidesDB engine as a plugin into stock MySQL 9.7.0 and 26.7.0, so TidesDB tables can sit alongside InnoDB tables in the same server. For now it installs with a script from the repository.
How easy is it to use the VillageSQL MCP extension?
Ronald Bradford
TL;DR - Ronald built and installed vsql-mcp on a throwaway server in about four minutes and answered a business question through a SELECT-only MCP user. His attempts to get past its guardrails were blocked.
Database News
Supabase is acquiring Turso
Paul Copplestone, Supabase Blog
TL;DR - Supabase is buying Turso, the team that rewrote SQLite in Rust, to build database infrastructure for AI agents. Turso founders Glauber Costa and Pekka Enberg join Supabase's leadership.
Amazon Aurora's analytics is DuckDB: a reproducible side-by-side with pg_duckdb
Franck Pachot
TL;DR - Franck puts Aurora PostgreSQL's aurora_analytics and pg_duckdb side by side. The EXPLAIN plans match, down to DuckDB's internal compression operators and constants, which shows that Aurora's S3 Parquet/Iceberg analytics runs on embedded DuckDB.
MariaDB Foundation Adds PostgreSQL to Its Engine‑Agnostic Testing Framework (TAF).
Jonathan Miller, MariaDB Foundation
TL;DR - TAF gains a PostgreSQL plugin and beta HammerDB TPROC-C/TPROC-H and Sysbench profiles, so MariaDB, MySQL and Postgres can be benchmarked under identical, reproducible conditions.
Scale without limits: Multigres, OrioleDB, and dbarena
Supabase Blog
TL;DR - At Supabase Select, the company launched three things. Multigres (pooling and multi-node failover for Postgres) is in private alpha. The OrioleDB storage engine is in public beta. dbarena, an open benchmark site comparing managed Postgres providers, is live.
When AI Finds the Bugs We Missed: A Very Busy Year for MariaDB Security
Frédéric Descamps, MariaDB Foundation
TL;DR - AI-assisted research drove 173 security reports over two quarters, which led to 27 published advisories and delayed some MariaDB releases. Update to the latest maintenance releases.
Benchmark Analysis with HammerDB TPROC-C(TPC-C) on TideSQL v5.1.0, InnoDB in MariaDB v11.4.13
Alex Gaetano Padula, TidesDB Blog
TL;DR - On a 3,000-warehouse TPROC-C run, TideSQL and InnoDB peaked at similar NOPM, but InnoDB had half the p99 latency. TideSQL held throughput at 128 VUs, where InnoDB dropped 34%. The author notes that one InnoDB setting was left untuned.
Influence Is Not Ownership: Anna Widenius and Kaj Arnö on Governance, Open Source, and the Future of MariaDB
Roberto V. Zicari, ODBMS Industry Watch
TL;DR - The MariaDB Foundation's leaders explain its newly formalised governance. Authority comes from contribution rather than employer, and there is a defined path from contributor to committer, reviewer and maintainer.
Designing Neki for performance
Dirkjan Bussink, PlanetScale
TL;DR - PlanetScale's sharded-Postgres router decodes lazily. Point lookups pass through as raw wire-protocol bytes, and only sort keys or row boundaries get decoded when a query needs them.
Working with foreign key constraints in Aurora DSQL
Rekha Reddy Anupati and Arnab Chowdhury, AWS Database Blog
TL;DR - Aurora DSQL foreign keys are checked against the transaction snapshot, and conflicting concurrent key changes fail at commit with SQLSTATE 40001. Cascades count toward the 3,000-row transaction limit, and existing tables can use NOT VALID plus async validation.
Upcoming Database Events
High Performance Transaction Systems (HPTS)
October 4-7, 2026
Asilomar Conference Grounds
Pacific Grove, CA
Open Source Summit Europe
October 7-9, 2026
Prague, Czechia
Community Over Code 2026
October 11-14, 2026
Hilton Glasgow
Glasgow, UK
TiDB SCaiLE 2026
October 15, 2026
Computer History Museum
Mountain View, CA
All Things Open 2026
October 19-20, 2026
Raleigh Convention Center
Raleigh, NC
PGConf.EU
October 20–23, 2026 (PostgreSQL Europe)
Valencia, Spain
P99 CONF 2026
October 21-22, 2026
Online
MySQL Public Discussion #6
October 22, 2026, 17:00–18:00 UTC
Online
Oracle AI World
October 25–28, 2026
Las Vegas, NV
PG Down Under 2026
October 30, 2026
Surry Hills
Sydney, Australia
MySQL Contributor Summit
November 4-5, 2026
Virtual
KubeCon + CloudNativeCon North America (VillageSQL is a sponsor)
November 9-12, 2026
Salt Lake City, Utah
PASS Data Community Summit
November 9-11, 2026
Hyatt Regency Seattle
Seattle, WA
PGConf.Asia 2026
November 17-18, 2026
Hong Kong
PGConf.PL 2026
November 24, 2026
ARCHE Dwór Uphagena
Gdańsk, Poland
AWS re:Invent 2026
November 30 – December 4, 2026
Las Vegas, NV
Open Source Summit Japan
December 7-9, 2026
Tokyo, Japan
CIDR 2027
January 24-27, 2027
Mövenpick Hotel Amsterdam City Centre
Amsterdam, The Netherlands
FOSDEM 2027
January 30-31, 2027
ULB Solbosch Campus
Brussels, Belgium
CERN PGDay 2027
February 12, 2027
CERN Council Chamber
Geneva, Switzerland
PGConf India 2027
March 2-5, 2027
Sheraton Grand Hotel at Brigade Gateway
Bengaluru, India
KubeCon + CloudNativeCon Europe 2027
March 15-18, 2027
Barcelona, Spain
Nordic PGDay 2027
March 16, 2027
Courtyard Kungsholmen
Stockholm, Sweden
SCaLE 24x
April 1-4, 2027
Pasadena Convention Center
Pasadena, CA
PgDay Boston 2027
April 10, 2027
Tufts University Joyce Cummings Center
Boston, MA
PGConf.dev 2027
May 11-14, 2027
Plaza Centre-Ville
Montréal, QC, Canada
|
