Anarchy in the Database: A Survey and Evaluation of

Database Management System Extensibility

Abigale Kim Marco Slot David G. Andersen Andrew Pavlo
UW–Madison Crunchy Data Carnegie Mellon University Carnegie Mellon University
abigale@cs.wisc.edu marco.slot@crunchydata.com dga@cs.cmu.edu pavlo@cs.cmu.edu

ABSTRACT DBMSs convert them into core features. For example, PostgreSQL’s
Extensions allow applications to expand the capabilities of database auto-vacuum started as a “contrib” extension in 2003 (v7.4 [1]) and
management systems (DBMSs) with custom logic. However, the became a built-in component in 2005 (v8.1 [2]).
extensibility environment for some DBMSs is fraught with perils, The database industry has recognized the importance of exten-
causing developers to resort to unorthodox methods to achieve sions for decades. Many leading systems support extensibility, in-
their goals. This paper studies and evaluates the design of DBMS cluding PostgreSQL [119], DuckDB [117], Oracle [55], MySQL [45],
extensibility. First, we provide a comprehensive taxonomy of the SQLite [104], SQL Server [43], Redis [93], and Elasticsearch [30].
types of DBMS extensibility. We then examine the extensibility There are even companies o�ering DBMS products based on exten-
of six DBMSs: PostgreSQL, MySQL, MariaDB, SQLite, Redis, and sions, such as Citus [24], TimescaleDB [112], and ParadeDB [56].
DuckDB. We present an automated extension analysis toolkit that Despite the bene�ts of extensions and wide adoption, there has
collects static and dynamic information on how an extension in- been almost no research into this aspect of DBMSs. Furthermore,
tegrates into the DBMS. Our evaluation of over 400 PostgreSQL some design decisions in DBMSs to make a system more extensible
extensions shows that 16.8% of them are incompatible with at least are fraught with problems. Unfettered extensions lead to unex-
one other extension and can cause system failures. These results pected errors or compatibility issues with other extensions, causing
also show the correlation between these failures and factors related the DBMS to produce incorrect results, corrupt data, or crash. In
to extension complexity and implementation. other cases, insu�cient APIs and support infrastructure cause ex-
tension developers to resort to bad practices, such as copying source
PVLDB Reference Format: code or exploiting existing APIs for uses other than their intention.
Abigale Kim, Marco Slot, David G. Andersen, and Andrew Pavlo. Anarchy This paper provides a thorough analysis of DBMS extensions
in the Database: A Survey and Evaluation of Database Management System from the perspective of system internals. We propose a taxonomy of
Extensibility. PVLDB, 18(6): 1962 - 1976, 2025. extensibility supported by DBMSs and their design considerations,
doi:10.14778/3725688.3725719 and then discuss the mechanisms that DBMSs can o�er to support
extensions. We use this taxonomy to survey six DBMSs: PostgreSQL,
PVLDB Artifact Availability:
MySQL, MariaDB, SQLite, Redis, and DuckDB. We discuss the good
The source code, data, and/or other artifacts have been made available at
and not-so-good aspects of each DBMS’s extension support. We
https://github.com/cmu-db/ext-analyzer.
then introduce ExtAnalyzer! [116], our automated analysis toolkit
for DBMS extensions. We evaluated 441 PostgreSQL extensions and
1 INTRODUCTION �nd that 16.8% are incompatible with at least one other extension,
There are two choices when building a DBMS to support a speci�c causing unexpected behavior and errors. Based on these results, we
use case. The �rst is to create a new system (or fork an existing one) provide guidance on how DBMSs can better support extensibility.
and customize it for the target workload and environment [152].
The other approach is to expand an existing DBMS through an
extension. An extension (aka plug-in) is custom code that adds new
2 BACKGROUND
features to a DBMS while maintaining its core functionality and To our knowledge, the �rst extensible DBMS was INGRES in the
infrastructure Examples of extensions include user-de�ned types, 1970s, with its support for UDFs written in C [153]. The academic
password authentication protocols, or a storage manager. version of INGRES also added UDTs in the early 1980s [143]. The
Extensions allow a DBMS to support more use cases with less INGRES developers then transferred this prototype’s design and
code than writing a new system. As the DBMS improves with new code into the initial version of PostgreSQL [151, 154].
features, such extensions ideally bene�t from these updates without In the 1990s and early 2000s, other DBMSs added support for
refactoring. They also reduce feature bloat in the DBMS, improving UDFs and UDTs, including Oracle [3, 5], IBM DB2 [135], and Mi-
engineering cadence by separating the DBMS’s development cycle crosoft SQL Server [8, 19]. MySQL v3.22 added its storage engine
from the extensions. In some cases, extensions are so bene�cial that interface in 2001 [145]. The SQL standard also included UDFs in
SQL:1996 [136] and UDTs in SQL:1999 [137]. Since then the trend
This work is licensed under the Creative Commons BY-NC-ND 4.0 International towards more DBMS extensibility has continued. MySQL began sup-
License. Visit https://creativecommons.org/licenses/by-nc-nd/4.0/ to view a copy of
this license. For any use beyond those covered by this license, obtain permission by
porting system plugins in 2004, while PostgreSQL added extension
emailing info@vldb.org. Copyright is held by the owner/author(s). Publication rights hooks in 2006. These extensibility mechanisms allowed applications
licensed to the VLDB Endowment. to override DBMS code, increasing extension development.
Proceedings of the VLDB Endowment, Vol. 18, No. 6 ISSN 2150-8097.
doi:10.14778/3725688.3725719 Some DBMSs provide extensibility as a �rst-class feature with
explicit methods of extending the capabilities of the DBMS. We

1962
exclude methods that rely on unintended behaviors or security validation rules (e.g., reject queries modifying speci�c tables). De-
breaches to add extensions (e.g., using code injection to add new velopers extend a DBMS’s parser by modifying its code or injecting
features instead of the core DBMS APIs). custom rewrite rules (MySQL’s Query Rewriter [52]).
Query Processing: The next type is a broad category of exten-
3 DATABASE EXTENSIBILITY TAXONOMY sions that modify the DBMS’s query processing stack, including its
This section presents our taxonomy of implementation design deci- planner and execution engine. The extensions that provide addi-
sions for DBMS extensibility. We begin in Section 3.1 with the types tional execution support either (1) modify only a small part of the
of extensibility that a DBMS can support. We then discuss the �ve execution path and, therefore, are smaller in scope or (2) rewrite the
areas of a DBMS’s architecture and environment for extensions: (1) entire query processing layer to support distributed execution or to
integration interfaces, (2) state modi�cation methods, (3) protection handle new physical data layouts (e.g., Citus [24], Timescale [112]).
mechanisms, (4) supporting components, and (5) developer APIs. Some query processing extensions collect runtime telemetry about
We discuss problems with real-world implementations of these �ve queries for performance analysis and debugging.
areas in Section 4. Although extending a DBMS in more ways than Storage Managers: A storage manager is responsible for or-
described here is possible, our taxonomy targets the most common ganizing, retrieving, and updating data on storage devices. Some
extensibility types in the most popular DBMSs. DBMSs allow extensions to replace their storage manager either
at the (1) �le access layer or (2) table access layer. The former is
3.1 Extensibility Types when an extension replaces the DBMS’s components interacting
An extension is user-provided logic that augments a DBMS’s be- with physical �les (e.g., SQLite’s Unix VFS [107]). For example, an
havior. This broad de�nition encompasses high-level extensions extension could retrieve object store data (e.g., Amazon S3) using a
(i.e., UDFs) and low-level extensions that rely on a DBMS’s internal non-POSIX API. Only the extension interacts with the object store
APIs. These types are not mutually exclusive, and many extensions to retrieve data; the rest of the DBMS is unaware of where that data
we examine in Section 5 comprise multiple types. came from, and the data’s interpretation remains the same. Other
User-De�ned Types (UDTs): A UDT provides a data type that extensions override a DBMS’s API for retrieving data from logical
does not already exist in the DBMS’s built-in type system. UDTs can tables. The most common are “connectors” that interact with tables
be logical aliases of an existing type or a combination of existing backed by external data sources. More expansive extensions involve
types (i.e., a struct). Some DBMSs support new custom physical concurrency control and bu�er management components [48].
types with their own binary encoding scheme and support func- Index Access Methods: Some DBMSs allow extensions to in-
tions (e.g., comparators and access methods). Examples of the latter troduce new indexes on top of its existing storage. Custom index im-
include vector embeddings [58] and LiDaR points [76]. plementations sometimes rely on UDTs. For instance, PostgreSQL’s
User-De�ned Functions (UDFs): Most DBMSs support UDFs pgvector [58] and DuckDB’s VSS [113] provide vector UDT indexes
written in procedural languages like PL/SQL or Python. The most for similarity search. Other index extensions leverage custom UDT
common UDF takes in scalar input arguments and produces either operators, such as PostgreSQL’s GiST [67].
scalar or table results. Another is a user-de�ned aggregate (UDA)
that takes in multiple rows of data as input and returns a single
scalar result. User-de�ned operators (UDOs) implement expression 3.2 Interfaces
operators such as “=” and “+” for UDTs via a UDF. Lastly, some A DBMS’s programming interface (API) determines how developers
systems support executing UDFs as standalone stored procedures. integrate their extensions into the system. The DBMS exposes this
Client Authentication: These extensions add or modify the API through a SQL interface or a procedural programming language
DBMS’s client authentication mechanisms and protocols. For ex- (PL). The API’s expressiveness determines whether an extension
ample, an extension could enable user authentication through an (1) adds new components to the DBMS or (2) overrides existing
external Kerberos server [34]. Some DBMSs allow extensions to components’ capabilities with custom logic.
change how they handle passwords internally, such as MySQL’s Adding Components: A DBMS can provide APIs to add new
validate_password [50] and PostgreSQL’s passwordcheck [71]. types, functions, and other components via handler functions with-
Utility Commands: The next group overrides or introduces out changing the system’s core functionality. An application then
administrative commands that read or modify the internal state of loads the extension into the DBMS and invokes the new functional-
the DBMS. These commands target a variety of database objects and ity explicitly (e.g., by calling the UDF). The APIs for adding compo-
system artifacts, including schema, permissions/ACLs, log �les [36], nents to the DBMS are limited and cannot support all extensibility
and con�guration settings. We also include package managers in types. Additionally, performance can su�er depending on the lan-
this category that install other extensions (see Section 3.6). guage and runtime context. For example, a Python UDF is slower
Parser Modi�cations: A DBMS parser validates the syntax of a to execute than a C/C++ UDF due to runtime overhead.
query and converts it into an internal representation for subsequent Overriding Components: Another approach is where exten-
optimization and execution. A parser extension could change the sions override parts of the DBMS’s code to augment it with new
query dialect the DBMS supports to add new syntax. Such exten- capabilities. The DBMS invokes the extension to perform some task
sions di�er from UDFs because they enable new syntactic features instead of using its original, built-in code. Consider an extension
in a DBMS’s query language that are not expressed as functions. that overrides the DBMS’s query execution: when a query arrives,
Alternatively, they may not change the syntax but instead change the DBMS bypasses its original code and invokes the extension to

1963
process it. One method of supporting overriding is via function extension support. The DBMS can diminish such threats by (1)
pointer hooks at various places in a DBMS’s source code. supporting extensions in safer languages (e.g., not C/C++), (2) dis-
allowing extensions from accessing sensitive data via internal APIs,
3.3 State Modi�cation and (3) placing restrictions on what extensions users can install.
These are preventative measures for malicious extension developers,
Most extensibility types in Section 3.1 access or modify state in the but they are not su�cient for security.
DBMS. There are four state types with di�erent implications for
how the DBMS supports them: (1) database state, (2) system state, 3.5 System Components
(3) extension state, and (4) ephemeral state.
We describe the internal components exposed to extensions.
Database State: This consists of a database’s logical contents
Background Workers: Most extensibility types modify the
and its physical structures. Database state consists of user data, such
critical path of query execution in the DBMS. Others implement
as tables, indexes, materialized views, and the metadata about these
asynchronous maintenance tasks that do not operate during query
objects. Extensions modify this state by either (1) submitting SQL
execution. Some DBMSs provide background workers for these
commands, (2) accessing table data via the host DBMS’s internal
tasks by spawning processes or threads to execute custom code.
API, or (3) modifying the contents of the database’s physical �les.
Examples of these maintenance tasks include garbage collection [4],
System State: This state is how the DBMS tracks its runtime
periodic job scheduling [73], and LSM compaction [70]. Extensions
operations independent of extensions. It includes the DBMS’s cata-
can invoke background workers by utilizing (1) custom APIs pro-
log, internal data structures that persist from one query to the next
vided by the DBMS or (2) native threads (e.g., POSIX threads).
(e.g., bu�er pools), and temporary data structures that the DBMS
Memory Allocation: When extensions store state in memory,
creates per query (e.g., plans). Extensions modify system state by (1)
they should utilize the DBMS’s built-in allocator instead of their
registering new components in the catalog (e.g., UDFs, UDTs), (2)
PL’s native allocators (e.g. malloc). Using the DBMS’s memory
writing into data structures passed to extension handler functions,
allocator allows the system to track memory via pools that are
and (3) updating data in shared memory.
coupled with the lifecycle of a query, transaction or session, and
Extension State: Each extension can also maintain data for its
cleared in case of error to avoid memory leaks. We found most
internal operations, including con�guration settings and metrics.
extensions use the DBMS’s built-in memory mechanisms.
Extensions store their state as (1) a database table, (2) an entry
Con�guration Options: Extensions can expose con�guration
in the DBMS’s catalog, or (3) in-memory data structures if their
options to allow users to customize their behavior without needing
contents persist across multiple queries. The �rst two rely on the
to recompile the source code. Common options include (1) resource
DBMS’s built-in recovery methods to ensure durability.
limits, (2) debug logging levels, and (3) other extension-speci�c
Ephemeral State: We deem any intermediate state that an ex-
settings. Most DBMSs expose registration functions to add new
tension modi�es during its execution but does not persist in the data-
options to the existing con�guration infrastructure. After new op-
base as ephemeral. Such state is usually related to query execution
tions are added, the users can set these options by (1) modifying
and only persists for the lifetime to a query (e.g., tuples projected
con�guration �les, (2) passing in command line arguments when
from an external table). Extensions create or modify ephemeral
they start up a database instance, or (3) writing SQL commands.
state within their runtime contexts. They can also pass this state to
Concurrency Control: To support parallelism, some DBMSs
the host DBMS for additional processing.
allow extensions to declare custom locks and use existing latches,
which are managed by the system. Extensions use locks to imple-
3.4 Protection Mechanisms ment concurrency control protocols or modify table data, and use
We now discuss how to ensure that extensions do not interfere with latches to synchronize access to extension managed memory or in-
one another and limit the DBMS’s exposure to security attacks. ternal data structures. Extensions declare and register custom locks
Isolation: To ensure extensions do not interfere with each other, by calling DBMS API functions in their source code, and leverage
a DBMS should isolate their e�ects. As we discuss in our analysis the host system’s existing concurrency control scheme.
in Section 5.4, we found examples where two extensions cause
problems when installed together, even if individually they do not. 3.6 Developer Ecosystem
One type of static isolation is to restrict the DBMS’s extension API. Lastly, we discuss the ways developers create extensions and how
For example, SQLite only allows one extension to control a given users manage them. These include the supported languages and a
extensibility pathway. Other methods include limiting allocations DBMS’s package manager, building tools, or testing infrastructure.
to a unique namespace with the appropriate ACLs. The level of Programming Languages: A developer’s �rst decision when
isolation provided by processes does not prevent resource manage- writing an extension is which PL to use since DBMSs often support
ment exploits using extensions. To mitigate this, the system could multiple languages. These include the language of the DBMS source
run an extension in a sandbox (e.g., container, jail) to restrict an code or SQL for UDFs and UDTs. Additionally, language binding
extension’s resource consumption to prevent out-of-memory or frameworks allow developers to create extensions in previously
priority inversion issues. unsupported languages. DBMSs implement these as foreign func-
Security: Unsafe extensibility opens the DBMS up to attacks tion interfaces (FFIs) bundled with their original API. Implementing
that access sensitive data and cause the system to malfunction. an extension overriding a DBMS component in the same language
Thus, it is imperative to consider security from the onset of adding as its source code is easier, as the extension can call the original

1964
 PostgreSQL MySQL MariaDB SQLite Redis DuckDB
User-De�ned Functions Yes (408) Yes (2) Yes (1) Yes (79) Yes (57) Yes (41)
User-de�ned Types Yes (139) No Yes (13) No No Yes (4)
Utility Commands Yes (43) No No No No No
Parser Modi�cations No Yes (2) Yes (1) No No Yes (4)
Query Processing Yes (46) Yes (7) Yes (5) No No Yes (4)
Storage Managers Yes (44) Yes (13) Yes (18) Yes (43) No Yes (9)
Index Access Methods Yes (67) No No No No Yes (3)
Client Authentication Yes (17) Yes (3) Yes (10) No No No
Version Examined v16 v8 v11 v3 v7 v1
Number of Extensions 441 29 68 98 57 44+
Table 1: DBMS Extensibility – An overview of extensibility types supported by the DBMSs considered in Section 4.

implementation as needed. However, it requires knowledge of the • DuckDB (2018) [117]: An embedded DBMS for analytics
target DBMS’s internals. Writing extensions in a high-level PL (e.g., written in C++ with a burgeoning extensibility ecosystem.
Python, JavaScript) results in less faulty code because extensions
address the DBMS’s state through abstractions and not directly. We �rst discuss which extensibility types each DBMS supports
This increases the security and isolation of the extension. (see Table 1). We then provide our analysis of each DBMS’s internals
Installation: Developers must also work with a DBMS’s APIs based on our taxonomy. Table 2 shows a summary of this survey.
for installing and removing extensions. Examples of installation in-
terfaces include (1) SQL commands, (2) separate extension manager, 4.1 Extensibility Types
and (3) con�guration �les. Similar to PLs, extension developers can
For each DBMS, we surveyed extensions found from three sources:
build on these installation interfaces to support a new API.
(1) GitHub, (2) o�cially supported internal extensions, and (3) ex-
Package Managers: Con�guring and installing many exten- tensions supported by cloud providers (e.g., Amazon, Microsoft).
sions on the same DBMS is di�cult. As a result, the DBMS or ecosys-
PostgreSQL: This DBMS supports the most extensibility
tem sometimes provide package managers to download, install, and
types (seven of eight) and supports relatively advanced features for
run tests on extensions. Package managers are implemented as (1)
each type. We found over 441 extensions, whereas the other DBMSs
command line tools, (2) websites, or (3) built-in utilities.
have less than 100 per system. PostgreSQL’s source code includes a
Build & Test Tooling: Developers rely on a DBMS’s infras- contrib directory with ⇠50 extensions. The DBMS supports UDFs
tructure to decrease the boilerplate code required to create a new written in C, SQL, or PL/pgSQL by default, but extensions can also
extension. Examples include build scripts and additional PL support. add new PLs [62, 63]. Combining UDTs, UDOs, and index access
Likewise, test tooling is also tedious to implement and an DBMS extensions enables specialized domains, such as geospatial [64] and
should ideally provide these to expedite extension development. vector search [58]. PostgreSQL extensions use query processing
hooks to provide alternative scan and join algorithms, or augment
4 SYSTEM SURVEY the planner and executor with additional functionality [128]. It also
Given this taxonomy, we qualitatively analyze how DBMSs support provides two forms of storage manager extensibility: (1) foreign
extensions. For each element in Section 3, we read the DBMSs’ data wrappers [84] for external tables (e.g., �le-based, other DBMSs)
documentation and then con�rmed our �ndings by examining their and (2) table access methods for local storage (e.g., columnar [25]).
source code. This survey aims to understand the prevalence of It is the only DBMS that supports utility command extensibility.
trade-o�s that DBMSs make when designing extensibility. We will MySQL: The DBMS’s installation package includes 44 exten-
provide a quantitative analysis of DBMS extensibility in Section 5. sions, but there are a small number of third-party extensions. There
We chose six DBMSs to examine based on (1) source code avail- are ⇠10 storage managers for MySQL [158], including InnoDB [48],
ability, (2) support for at least two extensibility types other than in-memory [49], and federated [47] engines. MySQL’s extension
UDTs/UDFs, and (3) usage popularity. The �rst criterion is critical, ecosystem is less active than PostgreSQL despite historical trends
but it unfortunately precludes the most popular enterprise DBMSs. of the former being more widely deployed than the latter.
• PostgreSQL (1986) [18]: This relational DBMS is written in C MariaDB: Since it is a MySQL fork, MariaDB has the same
and was designed at its inception to be extensible [154]. As such, extensibility types, but it added support for UDTs in 2019 [6]. Mari-
PostgreSQL has the most diverse extensibility network. aDB’s installation package contains 65 extensions, including 22
• MySQL (1994) [45]: This relational DBMS is written in C++ storage managers that are more specialized than the ones available
and is most known for its storage manager plug-in architecture. for MySQL [158]. Examples include text search [39], S3 backup [42],
• MariaDB (2009) [37]: A MySQL fork written in C++ that and parallel query execution [38].
supports more extensions than the original MySQL codebase. SQLite: This DBMS supports overriding its �lesystem ac-
• SQLite (2000) [104]: An embedded DBMS written in C that cess layer. Extensions use this extensibility to optimize storage for
works on the most varied hardware and operating environments. di�erent workloads, support additional operating systems, and im-
• Redis (2009) [93]: An in-memory key-value store written in plement security features, such as encryption [105]. SQLite restricts
C++. Its extensibility is unique because it only supports exten- overriding more than one �lesystem simultaneously. Apart from
sions that operate above the DBMS’s key-value storage. this, extensibility support in SQLite is minimal.

1965
 Redis: This DBMS’s extensibility support di�ers from the oth- describe in Section 4.1 Redis has some of the most diverse exten-
ers because it does not allow extensions to access its internal APIs. sions that transform the system into a di�erent type of DBMS (e.g.,
It only supports UDFs, which operate above the DBMS’s key-value graph [100], full-text search [99], relational [115]). This is akin
storage. Despite this limited support, Redis has an actively main- to building a full-featured DBMS (e.g., TiDB [134]) on top of an
tained catalog of 57 extensions. One of its most popular extensions embedded key-value DBMS (e.g., RocksDB [131]).
provides a new query and indexing engine [99]. Redis supports DuckDB: Similar to MySQL, this DBMS’s extensions add
extensions written in either C or Lua. components via handler functions. Since DuckDB is a C++ codebase,
DuckDB: Similar to PostgreSQL, DuckDB supports many extensions de�ne these functions in a class instead of structs. But
extensibility types. For example, it supports planner extensions DuckDB is switching to a C API for extensions to make it easier to
to add custom optimizer passes. It also provides vectorized UDFs, interoperate with other PLs [120].
which means that each invocation of the UDF processes a batch
of values to avoid the overhead of context switching. It enables 4.3 State Modi�cation
developers to override its catalog to support accessing external
Next, we consider the state types extensions can modify. Extensions
DBMSs, including PostgreSQL [28] and SQLite [29]. DuckDB has
that modify system state wield more control over the DBMS’s be-
modi�ed its parser to be extensible at runtime to allow extensions
havior to support expansive features. But if an extension is allowed
to add their own syntax without the need for UDFs [142].
to modify internal data structures, it can corrupt them, causing the
DBMS to crash or produce incorrect results.
4.2 Interfaces
PostgreSQL: Extensions access database and system state
We now examine the DBMSs’ interfaces for extensions. Extensions
via global functions and variables, and the DBMS passes ephemeral
that replace DBMS components have a wider variety of capabilities;
state into the extension via function arguments. Extensions can
some extensions override so much of a DBMS that they transform
create tables and other database objects to store extension-speci�c
it into a di�erent system. For example, Citus [24] turns PostgreSQL
state, but they must also handle upgrades and dump-and-restore
into a distributed DBMS. Maintaining such complex extensions is
scenarios. PostgreSQL also allows extensions to register functions
di�cult because developers must ensure compatibility as a DBMS’s
for copying and (de)serializing data structures. Extensions often
API evolves with newer versions. When a DBMS’s interface does
use this functionality to inject data into query plans.
not provide developers with what they need, they resort to using
brittle methods, like duplicating the DBMS source code. MySQL / MariaDB: They allow extensions to create data-
base objects (e.g., tables), access system state via C-style pointers,
PostgreSQL: The DBMS provides mechanisms to add func-
use the built-in memory allocation mechanisms for extension state,
tionality via handler functions for UDTs, external tables, storage
and de�ne ephemeral state.
engines, and index access methods. One problem with PostgreSQL’s
UDT API is that some handler functions are optional, which causes SQLite: Its extensions can use the built-in memory allocator
problems when using them with index extensions if not imple- to access ephemeral state. Both SQLite’s virtual table (i.e., connec-
mented (see Section 5.4). PostgreSQL provides the other extensibil- tors) and �lesystem extensions access system state via arguments
ity types by allowing extensions to override DBMS functionality to their handlers. Although extensions cannot create new databases,
via hooks in parts of its code. The DBMS declares hooks as function they can write tuple data in database �les to modify state.
pointers in global variables that it will call instead of its code if the Redis: Its extensions can modify all state types except sys-
hook is set. Extensions replace a part of PostgreSQL’s functionality tem. Extensions can store metadata or database contents inside the
or perform additional steps before or after calling the original code. DBMS’s built-in key-value store, use built-in memory mechanisms,
As of 2024, PostgreSQL supports 34 hooks. and de�ne ephemeral state in their source code.
MySQL / MariaDB: Their interfaces for adding compo- DuckDB: The DBMS exposes its system state via top-level
nents is similar to PostgreSQL. However, instead of setting hook database session instances and extensibility interfaces. Extensions
pointers, their extensions set handler functions in structs. The can also augment the DBMS’s C++ classes with ephemeral state.
DBMS stores extension metadata, including the addresses of the They can create tables and store state in the database, though such
handlers, in its catalog. Then, it searches and invokes the exten- facilities are limited.
sion at various points in the code. Each extension has a single type
association and thus cannot contain multiple types of extensibility. 4.4 Protection Mechanisms
SQLite: The UDF and storage manager interfaces support We next analyze the protection mechanisms in the DBMSs. There is
adding components via handler functions. Similar to MySQL and contention between how much freedom a DBMS gives extensions
MariaDB, extensions set handler functions in structs, and the DBMS and how vulnerable it makes the system. Query-invoked extensions
invokes the extension when the component is used. SQLite allows (e.g., UDFs) can circumvent a DBMS’s ACLs since they execute as
extensions to override �lesystem functionality by replacing system the calling user and not the original user that installed it [14]. If
call wrapper functions (e.g., open, read, write). users can install extensions written in an unsafe language, the only
Redis: This DBMS has the most restrictive API that only protection is whatever the OS provides. If extensions run in the
supports UDFs (called “commands” [95]) that process query com- DBMS’s address space, the OS cannot prevent them from accessing
mands and read/write data via its storage layer. Redis UDFs cannot certain resources. Such problems are why DBaaS vendors restrict
override core DBMS functionality. Despite this limited API, as we what extensions a user can enable. Static analysis methods and

1966
 PostgreSQL MySQL MariaDB SQLite Redis DuckDB
Adding Components Yes Yes Yes Yes Yes Yes
Overriding Components Yes Yes Yes Yes No Yes
State Modi�cation All state All state All state All state Etxn. + Ephmrl. All state
Isolation/Security None Low Low Medium High Low
Background Workers Yes Yes Yes No No No
Memory Allocation Yes Yes Yes Yes Yes Yes
Con�guration Options Yes Yes Yes No Yes Yes
Source Code Yes Yes Yes Yes No Yes
Programming Languages C, C++, Rust C++ C++ C, Rust C, Lua C++
Installation Interface SQL, con�gs SQL SQL SQL SQL, con�gs SQL
Build & Test Tooling Both Testing Testing Both None Both
Package Manager Yes (community) No Yes (OS) Yes (community) No Yes
Table 2: Extensibility Support – An overview of extensibility support for the DBMSs evaluated for the survey in Section 4.

runtime sandboxing could prevent some problems with unsafe ex- the extension API [7, 10]. SQLite supports disabling extension load-
tensions, but none of the DBMSs we examined do these. Enterprise ing to prevent such attacks and SQL injections. Since SQLite is in
DBMSs (e.g., Oracle [118]) execute extensions as a separate process. C, it is prone to language-supported security attacks.
PostgreSQL: Users’ calls to UDFs in higher-level languages Redis: This DBMS is the most isolated in our survey, as all
are subject to regular database ACLs. However, it is possible for an its extensibility types do not interact with one another. Since the
extension to de�ne UDFs with administrative privileges. An admin- DBMS is written in C, it is also prone to language-related security
istrator normally loads extensions, though installation interface attacks. For example, pam_auth [98] overrides the client authenti-
issues create opportunities for less privileged users to gain higher cation component of the DBMS without an established interface. It
privileges [11, 13, 17]. An administrator can mark extensions as supports ACLs to disallow users from installing extensions.
“trusted” to allow less privileged users to load them [66]. DuckDB: The APIs in DuckDB prevent extensions from over-
Extensions written in C have no restrictions once called via a riding each other, though they can sometimes alter each other’s
hook. Low-level functions for reading and writing to the database state. For instance, optimizer extensions have access to the same
are not subject to access controls since the DBMS only enforces query plan data structure. To prevent exploits, DuckDB crypto-
those at the planning and execution layer. It is up to the exten- graphically signs its core extensions and community repository
sion developer to enforce ACLs. PostgreSQL provides a keyword extensions. The DBMS is also prone to some language-level attacks,
SECURITY LABEL[87] which provides access control for extensions. but it mitigates them using modern C++ memory constructs.
Multiple extensions can interfere with each other when they
use the same hook. Thus, the end-to-end behavior of combining
multiple extensions may be unpredictable. Some extensions require 4.5 System Components
the DBMS to invoke them last to avoid interference, which causes We now describe the internal mechanisms that the DBMSs provide
problems if two extensions have this requirement. Suppose a hook to developers to help them create extensions. The DBMS’s system
is already set by extension A when extension B is loaded, and B components impact extension design by making development more
sets it to its function. In that case, the convention is for B’s function convenient. Implementing workarounds for components that do
to call the original hook (A’s function) to form a chain of function not exist or have unsuitable APIs is also possible. For example, ex-
calls, but the DBMS does not enforce this, and the extension may tensions can create database tables to store metadata, even without
make changes to the data structures passed as arguments. We study memory allocation APIs.
this issue further in Section 5.4. PostgreSQL: The DBMS has a large C codebase where some
MySQL / MariaDB: Since the DBMS handles extension functions and variables de�ned in header �les are accessible to ex-
invocation, one extension cannot modify another’s execution. The tensions. Extensions allocate short-term memory using the DBMS’s
DBMS attempts to ensure extensions do not overwrite each other’s built-in region-based allocator; the DBMS automatically releases
state, but this behavior is not guaranteed. For auditing plugins, the this memory at the end of the current operation or transaction. Ex-
DBMS passes the same event state to each plugin, which allows tensions can also request long-term memory to share state across
other extensions to modify it. Because most of MySQL’s extensions its process-based sessions. PostgreSQL provides specialized back-
are in C/C++, it is prone to security vulnerabilities. For example, ground workers that work with its process-per-worker model. Ex-
users with low privilege access can execute denial of service at- tensions can also de�ne new con�guration options. Users set these
tacks [12, 46]. Like PostgreSQL, MySQL’s allows developers to options via SQL or regular con�guration �les. Allowing users to
specify whether an extension requires higher privileges to install. change options via con�guration �les is unique to PostgreSQL.
SQLite: Most extensibility types cannot interact, and the MySQL / MariaDB: They both provide generous extensi-
DBMS only allows one �lesystem extension at a time. Like other bility mechanisms to developers. For example, the DBMS’s daemon
DBMSs, a malicious user can cause denial of service attacks through extensibility allows extensions to spawn additional threads. This
is similar to background workers, although it is supported di�er-
ently within the DBMS. Extensions using daemons typically run
one process in the background to perform various tasks. On the

1967
other hand, extensions using background workers use them to MariaDB: Its ecosystem is similar to MySQL but has better
supplement existing functionality (e.g., garbage collection for an documentation and a tool for managing extensions [41]. MariaDB
index). also relies on OS package managers (e.g., Debian apt, Redhat yum)
SQLite: The DBMS provides a C header [111] that gives ex- for distributing and upgrading extensions [40].
tensions access to all its API routines. These include concurrency SQLite: There is no DBMS-provided build infrastructure for
control, memory allocation, and string processing functionality. extensions written in C, but there are community-driven e�orts for
Redis: It provides a dynamic memory allocation API that other PL frameworks [106, 109]. Developers compile extensions into
allows extensions to allocate and free memory. Redis also provides shared library objects and load them through SQL commands. They
an extensive utility API, allowing extension developers to call its can also write tests using SQLite’s built-in Tcl testing framework.
internal commands from their extension code. It does not o�er SQLite has one community package manager (sqlean) [108].
its core source code for extension developers. Instead, extension Redis: The DBMS supports extensions written in either C
developers build extensions using the key-value store as needed or Lua (UDFs). RedisModulesSDK [97] is a collection of utility func-
instead of directly modifying Redis. tions, test tooling, and documentation to help developers write
DuckDB: It uses C++’s memory management features (e.g., extensions. The redismodule-rs is a framework for writing exten-
smart pointers) to mostly obviate the need for custom allocation sions in Rust. Redis does not have a package manager, but its o�cial
primitives, but a custom allocator is available for allocating data documentation used to provide a list of popular, vetted extensions
bu�ers. Extensions can add data structures to maps tied to the extensions [96]; this list was removed as part of Redis’ re-branding
session or database instance. Extensions can also extend classes in and license change in 2024 [94].
DuckDB’s source code to add new functionality. DuckDB relies on DuckDB: The DBMS provides a C++ extension template that
conventional C++ mutexes for concurrency control, and extensions includes build and test infrastructure. Extensions compile to shared
can do the same. Since DuckDB is an embedded DBMS, it does not libraries. When the DBMS loads an extension, it installs objects like
support background workers. Extensions add con�guration options functions and types to its catalog. DuckDB also provides extensibil-
by calling internal functions upon initialization. ity that targets local applications. For instance, developers can use
the C API to de�ne custom scans and the Python API to de�ne cus-
tom UDFs in Python, though we do not consider such programs in
this paper. DuckDB is the only DBMS that has a built-in extension
4.6 Developer Ecosystem manager. When users install an extension with SQL commands,
We discuss methods for creating and installing extensions. A com- the DBMS downloads it from either a DuckDB-managed repository
mon problem is ensuring version compatibility when a DBMS’s or third-party repository [27]. Developers can also manually link
API changes. If a DBMS does not require an extension to provide extensions into the DuckDB binary.
a supported versions list, developers resort to two methods. First,
they release separate variants of their extension for each DBMS 5 EXTENSION ANALYSIS
version, which imposes an maintenance burden on developers and Our survey in Section 4 provides a qualitative overview of DBMS
users. Alternatively, developers write explicit version handling in extensibility in widely used systems. To better understand how
their extensions, increasing the code’s complexity and brittleness. extensions use these features in the real world, we next analyze the
PostgreSQL: SQL scripts de�ne the DBMS extensions to implementations of PostgreSQL extensions. We examined the other
create database objects and an optional shared library with in- DBMSs but found no incompatible extensions, and the amount of
ternal functions and hooks. Developers can write a shared library copied code was minimal. We discovered that 15.5% of DuckDB
in C, C++, or Rust (pgrx [86]). pg_tle [89] also enables developers extensions contained code from the DBMS, which was all less than
to write extensions in procedural languages. Extensions can be 3%. Most of the code copied by SQLite and Redis extensions were
installed via package repositories, compiling the extension from from their extension header �les. Lastly, we found that MySQL and
source, or a specialized extension manager (e.g., PGXN [59]). No MariaDB have no extensions with copied source code.
o�cial extension manager exists, but PGDC [68] distributes com- In this section, we evaluate PostgreSQL’s extensibility in three
monly used extensions. Some extensions require users to modify ways. The �rst two rely on static analysis of the extensions’ source
con�guration �les to load them on startup. code (Sections 5.1 and 5.2). Our third evaluation step runs the
PostgreSQL provides two extension development tools: (1) PGXS [60] extensions in the DBMS and observes their behavior (Section 5.4).
(build system for extension development) and (2) pg_regress [57] We created the Extension Analyzer Toolkit (ExtAnalyzer! [116])
(opaque-box testing for extensions). for this investigation. The toolkit automatically downloads and in-
MySQL: Extensions are SQL scripts with UDFs or shared stalls PostgreSQL v16 [18] extensions from the following sources: (1)
library objects written in C++. The DBMS does not have build PostgreSQL’s contrib directory [16], (2) supported extensions from
tooling, so extensions create their own. It provides example modules AWS RDS [20], Google Cloud SQL [33], and Azure PostgreSQL [22],
and testing infrastructure, although extensions sparingly use the (3) PostgreSQL Extension Network (PGXN) [59], and (4) other pop-
latter. Users install extensions with SQL commands or by passing ular extensions (e.g., Citus [24], TimescaleDB [112], PostGIS [64]).
in a con�guration option at server startup. Our survey did not �nd Since we do not know which extensions are the most used, the
any extension package manager for MySQL. This lack of support is supported extension list from the cloud vendors is a suitable ap-
notable, given that the MySQL extensibility has many features. proximation and 89% of them are open-source.

1968
 Rank Categorization Info # of Extensions
#1 N�� I������ 55 (67.9%)
UDFs, UDTs, index access methods
#2 ���� P��������� F������� 17 (21.0%)
UDFs, query processing, utility cmds
#3 UDT���������� ���� E����� 4 (4.9%)
UDFs, UDTs, storage mgr., query proc.
#4 N�� S������ M������ 4 (4.9%)
UDFs, storage manager, utility cmds
#5 F������������ E��������� 1 (1.2%)
Figure 1: Distribution of Extensibility Types – The number of exten- All extensibility types
sions using each extensibility type, grouped by number of types used. Table 4: Complex Extension Categorization – An overview of the ex-
Extensibility Type # of Extensions tension categories found by the K-modes clustering algorithm.
User-De�ned Functions 408 (92.5%)
We convert each extension’s extensibility types into a one-hot
User-De�ned Types 139 (31.5%)
Index Access Methods 67 (15.2%) encoding and then cluster them using K-modes [124]. We found
Storage Managers 44 (10.0%) that �ve clusters provided the most meaningful results through the
Client Authentication 17 (3.9%) elbow method. Then, we manually each group of extensions (shown
Query Processing 45 (10.2%) in Table 4). All categories use UDFs, which are required for other
Utility Commands 43 (9.8%) extensibility types. The most common category is new data types
Table 3: Extensibility Types – The number of PostgreSQL extensions per with type-speci�c indexes. One example is pgvector, an extension
extensibility type evaluated in our experiments. that implements a custom embedding type and an HNSW index to
retrieve them e�ciently. PostgreSQL has supported custom types
5.1 Source Analysis: Extension Characteristics and index access methods since 1995 [133], whereas it added query
We �rst measure the prevalence of extensibility types (Section 3.1) processing extensibility in the mid-2000s [26, 91, 103].
and system components (Section 3.5) to understand how real-world The second complex extension category targets query processing.
extensions use these elements. For each extension, our analysis These extensions combine query processing and utility hooks to
toolkit downloads its source code, extracts relevant code, and checks provide additional functionality for each command (e.g., statistics
for keywords that indicate usage of an extensibility feature. Since collection). Storage manager extensions add foreign tables or access
our toolkit can produce false positives due to keyword misuse, we methods with table-level utility commands (e.g., COPY or TRUNCATE).
manually inspected a random sample of the extensions to verify that New query engines with UDTs add storage and execution features
the analysis works as intended. Extensions declare which hooks for custom types. The smallest category in our cluster is the full-
they want to override in their initialization code. The toolkit also featured extensions that transform PostgreSQL into a new DBMS
extracts SQL keywords that install di�erent components of the by adding layered features on top of it; the only extension in this
extension (e.g., CREATE FUNCTION). We count the number of extensi- category is Citus [24]. It includes a custom planner for distributed
bility types per extension. We then identify combination groupings queries, columnar table storage, and UDFs/UDTs.
of extensibility types in the more complex extensions.
Figure 1 groups extensions by the number of extensibility types 5.2 Source Analysis: Duplicate Code
used and shows the number of extensions that use a speci�c type
We next evaluate the source code quality of PostgreSQL extensions
within each group. In addition, Table 3 presents the number of
to understand whether the DBMS’s API su�ciently supports the
extensions using each type. UDFs are the most common type; over
extensions’ use cases or whether developers contort the system
92% of extensions use them. This pervasiveness is expected because
to implement their features. We look for two problems that we
PostgreSQL extensions use UDFs for user-facing features and to
observed while surveying these extensions. The �rst is when devel-
de�ne other extensibility types (e.g., UDTs).
opers copy large amounts of the DBMS’s code into their extensions.
The second most common extensibility type is UDTs, with ⇠32%
The second problem is when extensions have custom logic for API
of extensions using them. Extensions are more likely to employ
changes in DBMS versions (see Section 5.3).
UDTs when combined with other types. All but one extension
To identify duplicate code, the toolkit extracts two metrics from
creates UDTs using C/C++ code handlers (represented as UDFs) to
each extension: (1) total number of code lines and (2) number of lines
read and write the type representation into memory.
copied from PostgreSQL’ source code. We use PMD Copy/Paste
Most extensions are simple and only use one or two extensibility
Detector (CPD) [31] to �nd duplicate code blocks. We provide CPD
types. 81 of 441 (⇠20%) extensions use three or more types, and
with each extension’s source code and PostgreSQL source code. The
we classify these as complex extensions. Of these extensions, 31 of
toolkit then examines code blocks with a minimum length of 100
81 (35.6%) use (1) client authentication, (2) query processing, or (3)
tokens (i.e., the smallest unit of a PL with meaning). CPD records
utility command types, which means they use hooks and override
false positives when it determines that an extension duplicates its
functionality in the host DBMS. We also observed that 36 of 81
own code and the toolkit omits these cases in our results.
(44.4%) extensions with three or more extensibility types leverage
We found 73 of 441 extensions (16.6%) include at least one line
the DBMS’s system components described in Section 4.5.
of copied PostgreSQL code. The histogram in Figure 2 shows the
distribution of these extensions based on the percentage of copied

1969
Figure 2: Duplicate Code – Distribution of extensions based on the per- Figure 3: Percentage of Function Code in Extensions – Distribution
centage of copied PostgreSQL code in their codebases. of extensions based on the percentage of lines of copied code consisting of
whole functions.
Extensibility Type # of Extensions
User-De�ned Functions 29 (93.5%) each major DBMS version. An example of an extension that does
User-De�ned Types 18 (58.1%) this is rum [101] (inverted index for full-text search), which has over
Index Access Methods 7 (22.6%) 10k lines of copied code related to sorting tuples that only changes
Storage Managers 0 (0%)
slightly from one version of PostgreSQL to the next. Maintaining
Client Authentication 3 (9.7%)
Query Processing 5 (16.1%) a codebase with copied functions is laborious and results in many
Utility Commands 6 (19.4%) bugs. For example, Citus’ GitHub repository contains 44 issues
Table 5: Duplicate Code per Extensibility Type – Number of extensions related to problems with PostgreSQL copied functions [24]. We
with > 10% copied code (31) using each extensibility type. discuss the implications of this issue further in Section 6.5.

code relative to their entire codebase. The biggest “o�ender” is

pg_ivm [75] (incremental view maintenance) where over 75% of its
5.3 Source Analysis: Versioning Logic
code is copied from PostgreSQL! Given the above example with the profuse copied code based on ver-
We ran an additional cross-analysis on the extensions with more sions, we next measure how often extensions include such custom
than 10% copied code to understand what di�erentiates them. Ex- logic. This provides insight into how often extension developers
tensions copying source code use more UDTs, index access meth- must handle changes in the DBMS’s internal API. For each exten-
ods, client authentication, query processing, and utility commands sion, our toolkit analyzes its code to determine whether (1) it uses
than others. All extensibility types that require hooks are on this versioning logic, (2) the number of versions supported, and (3) how
list. When setting these hooks, an extension should preserve the many lines of code are version-speci�c. The toolkit identi�es pre-
DBMS’ original functionality and may need to call existing func- processor directives (#ifdef) in the code using the PostgreSQL’s
tions. Extensions that use storage manager APIs have little dupli- PG_VERSION_NUM macro, and then calculates the number of lines of
cated code. A possible explanation is that PostgreSQL’s storage code encapsulated in these versioned conditionals.
manager APIs were created in tandem with related extensions (e.g., Figure 4 shows the distribution of the extensions’ code wrapped
postgres_fdw [84]), so any gaps in those interfaces would have in versioning logic, with 153 of 441 (34.7%) extensions using it at
been apparent during development. least once; 38 of these 153 (24.8%) extensions are supported by
Through a manual inspection of the copied code and discussions the cloud vendors. Although versioning exists in a third of the
with developers, we found that extensions copy PostgreSQL’s code extensions, on average only 5.8% of their code is version-speci�c.
for three reasons. Foremost, extensions often need to use built-in We also ran a cross-analysis on extensibility types to explain
functions within the PostgreSQL source code. However, those func- why some extensions contain more versioning logic than others.
tions are declared static in the code, meaning any other code that Table 6 shows query processing (41.9%) and utility command (48.4%)
wants to call the function must reside in the same �le as the func- extensions have more versioning logic. These extensions rely on
tion’s de�nition (this is a C restriction). Therefore, developers resort internal representations of query plans and execution engine logic
to copying these functions into their repository so their extension that often changes between versions. For example, the function sig-
can call them. This is the reason why pg_ivm contains so much nature for PostgreSQL’s utility command hook changed four times
copied code. We found that 29 of 73 (39.7%) extensions that dupli- in the last decade. But not all extensions using these extensibility
cate code contain copied entire functions. In other cases, extensions types contain versioning logic: 13 of 45 (28.9%) query processing
copy functions but change small parts of their functionality to suit and 12 of 43 (27.9%) utility command extensions do not handle
their needs. Lastly, we identi�ed cases where extensions copy a versioning. The developers for these extensions instead release
portion of logic from PostgreSQL code but not entire functions. separate binaries for speci�c PostgreSQL’s versions. This analysis
To di�erentiate between these three scenarios, we measured highlights that PostgreSQL API inconsistency between versions
what percentage of each extension’s lines of copied code resides in causes developers to write more convoluted code.
an entire function from PostgreSQL. Figure 3 shows the percentage
of copied code relative to an extension’s total number of lines of 5.4 Runtime Analysis: Compatibility
code. These results show that an average of 42.7% of copied code
As discussed in Section 4.2, PostgreSQL has the most permissive ex-
consisted of entire functions. One common anti-pattern is when
tension API out of the other DBMSs. Our last experiment measures
an extension contains a copy of the same PostgreSQL function for
how PostgreSQL’s �exible API impacts extension isolation.

1970
 Extensibility Type # of Extensions
User-De�ned Functions 22 (71.0%)
User-De�ned Types 3 (9.7%)
Index Access Methods 1 (3.2%)
Storage Managers 6 (19.4%)
Client Authentication 4 (12.4%)
Query Processing 13 (41.9%)
Utility Commands 15 (48.4%)
Table 6: Versioning Logic per Extensibility Type – Number of exten-
sions with >10% encapsulated versioning code (31) per extensibility type.

Figure 5: Compatibility Tests – Left matrix shows the results of all

compatibility testing. Right matrix shows the results of the 20 extensions
with the highest failure rate.

background worker synchronization bug. plprofiler [61] con-

Figure 4: Versioning Logic – Distribution based on the percentage of �icts with 12 of 95 (12.6%) extensions due to a shared memory
encapsulated versioning code in extension codebases. initialization error.
• Brittle Con�guration Settings: Since test_decoding [88] and
We test all unique pairs of extensions to evaluate their compatibil- wal2json [114] are both logical decoding extensions, they use
ity. Two extensions are deemed compatible if our toolkit completes replication slots. Their tests produced an error due to too few
three steps: (1) installs them into the same DBMS instance, (2) runs allocated replication slots.
the extension-provided unit tests, and (3) runs pgbench [65]. Run- • Memory Errors: The toolkit caused the DBMS to crash due to a
ning pgbench in the last step provides a smoke test to determine segmentation fault with pg_show_plans [80] and pg_repack [78]
whether the rest of the DBMS still functions correctly with the when the former runs out of memory. The same crash occurs
extensions installed. We also separately test each UDT and index when logerrors [35] and plprofiler [61] run out of memory.
extension combination. We use Claude v3.5 Sonnet [127] to auto- • UDO Incompatibilities: PostgreSQL misinterprets UDOs for
matically generate an SQL script that populates a small table with a several extensions [69, 70, 72, 85] as their own. When their func-
UDT column and then attempts to build an index on that column. tion signatures do not match the DBMS’s API, it errors out.
Some failures only occur when the toolkit installs one extension • Query Processing Bugs: If the DBMS uses timescaledb [112]
�rst because it determines the order in which the DBMS invokes with pg_hint_plan [74], then the latter is unable to override
them. Hence, for each extension pair, our toolkit installs them in the query’s join order, causing unexpected behavior. Installing
both permutations (i.e., A!B, B!A). We ran these tests in our pg_stat_monitor [82] together with pg_stat_statements [83]
toolkit for the 96 extensions with the necessary installation scripts. causes the former to record incorrect data in its auxiliary tables.
Our tests found that 16.8% of extension pairs failed to work • Installation Order: The DBMS fails to start when it does not
together. The matrix in Figure 5 shows the compatibility testing load (1) citus [24] �rst or (2) pg_queryid [77] last.
results. Each green square in the graph indicates a successful, com-
patible pair of extensions, while each red square indicates that the These failures indicate there are rampant compatibility issues
pair of extensions failed to operate together correctly. The exten- between extensions. We next identi�ed what aspects of their imple-
sions in the graph are sorted from lowest to highest compatibility mentations cause problems. We ran paired T-tests with a p-value of
failure rate. This �gure reveals that while most extensions are com- 0.1 on the compatibility failure rates. Although there are risks with
patible with one another, some extensions have higher failure rates. using paired T-tests on multiple hypotheses, we decided to run tests
The zoomed view in Figure 5 highlights the 20 extensions with on many extensibility factors to determine possible correlations.
the highest failure rates. Of these tests, 255 of 380 (67.1%) fail and We split them into two groups based on whether an extension:
about a quarter (29.2%) of those fail due to brittle test cases. Most
PostgreSQL extensions use the built-in testing harness (pg_regress). • Uses a certain hook in their source code.
The problem with this harness is that it uses string comparisons • Uses more than = hooks in their source code (= = [0, 7]).
on the output of SQL commands to determine whether a test case • Utilizes a certain extensibility type.
succeeds. When our toolkit loads multiple extensions together, it • Contains source code copied from PostgreSQL.
can change the output of some commands (e.g., catalog queries) • Contains versioning logic.
and cause spurious test failures. • Contains more than = lines of source code (= = {500, 750, 1000}).
Through manually examining our output, we found bugs in • Uses more than = extensibility types (= = [1, 4]).
extensions and parts of PostgreSQL. We discuss these below: • Uses certain system components.

• Extension Bugs: lsm3 introduces a latch deadlock that causes Of the 55 factors we considered in our T-paired analysis, we
the DBMS to hang with 16 of 95 (16.8%) extensions due to a found that the following have the strongest correlation to failures.

1971
 Feature p-value
Function Usage 1.13e-6
A���.

Storage Manager Component 0.0375

Duplicate PostgreSQL Code 0.0172
C���

More than 1000 LOC 0.0448

More than 750 LOC 0.0915
More than 3 Components 0.0920
More than 3 Hooks 0.0715
I���.

More than 4 Hooks 0.0023

More than 4 Components 0.0015 Figure 6: Safety vs. Flexibility – An approximation of how the DBMSs
Table 7: Failure Correlations by General Features – Lists the p-values consider safety vs. �exibility trade-o�s from Section 6.1.
associated with each of our paired T-tests grouped by the extensions’ archi-
tecture (A���.), source code (C���), and implementation (I���.) features. MySQL, MariaDB, and DuckDB are more diverse. On the other
hand, we showed in Section 5.4 that a too-permissive extensibility
The foremost reason is that higher complexity causes lower compat- API can have stability issues.
ibility: if an extension uses many system components, extensibility
types, or hooks, it is more likely to break other extensions.
6.2 Extension Composability
Second, using larger-scope query planner and execution hooks
(e.g., planner_hook, ProcessUtility_hook) and smaller scope hooks Our survey showed that DBMS extensibility is not inherently com-
(e.g., set_join_pathlist_hook) decreases compatibility. Using such posable. There is no built-in way for an extension to reference
hooks in an extension requires a deep understanding of the DBMS’s another extension’s code, components, or state. Instead, developers
query engine to ensure that it does not cause problems; if two exten- rely on their understanding of an extension and then implement
sions modify the same query engine state, they break unpredictably. their extension to match this behavior. This does not stop develop-
Other codebase complexity measures, such as duplicate code ers from using extensions as dependencies in their implementations.
usage or having a larger codebase, also decreased compatibility. This For example, many PostgreSQL extensions [74, 77, 79, 81] rely on
aligns with our observations since extensions with these features pg_stat_statements [83] to obtain planning and execution statis-
require more maintenance and e�ort to ensure they work correctly. tics. Another example is the InnoDB-speci�c catalog extensions
Using UDFs correlates to failures since many complex extensions in MySQL and MariaDB. These examples provide a compelling
use UDFs. Notably, extensions only using UDFs had an average argument for DBMSs to support extension composability formally.
compatibility failure rate of 10.7%, while extensions that used UDFs PostgreSQL’s hook “chaining” is the root of many problems we
and other extensibility types had an average failure rate of 22.2%. identi�ed, as it creates a new call path that an extension is unlikely
to test beforehand. PostgreSQL requires that any extension that
connects via a hook must also call the previously set hook to ensure
6 DISCUSSION both extensions are called, but it has no way of checking whether
We now summarize our �ndings on DBMS extensibility and pro- an extension complies with this. Furthermore, extensions might
vide recommendations for developers who want to add or improve call internal query execution functions that then call other hooks.
extension support in a DBMS. PostgreSQL has the most comprehen- Such chaining means the DBMS might invoke an extension in an
sive extensibility APIs and the largest extension ecosystem. Many unfamiliar state. Given this, using a SQL interface over low-level
of its design decisions are worth replicating in other DBMSs, but hooks (e.g., event triggers for DDL changes) is preferable.
our survey and analysis also showed that it is not without its �aws.
6.3 Extension Redundancies
6.1 Safety vs. Flexibility
Our survey reveals that many extensions re-implemented the same
Designing extensibility with the proper safety mechanisms means functionality for di�erent DBMSs. For example, both MySQL and
ensuring the DBMS will not produce incorrect results or crash. This PostgreSQL have job scheduling extensions: mysql_query_queue [51]
goal can con�ict with the desire to support expansive extensions and pg_cron [73]. Almost all the DBMSs also have vector index ex-
that can modify the DBMS’s runtime behavior. An example of opt- tensions: PostgreSQL’s pgvector [58], SQLite’s sqlite-vss [110],
ing for safety is SQLite’s limitation that only allows one �lesystem DuckDB’s duckdb_vss [113], and MySQL’s mysql_vss [53]. To re-
extension at a time to avoid compatibility issues. PostgreSQL is the duce this repetitive e�ort, we argue that the database community
other extreme, where extensions are unrestricted in manipulating should develop a standardized POSIX-like API [129, 146] for exten-
the core system and each other. sions so that DBMSs can share extensions.
Figure 6 shows the six DBMSs surveyed on the safety-�exibility
spectrum. We consider PostgreSQL’s framework the most �exible
and Redis’ the safest. We consider Redis the least �exible because 6.4 DBMS Extensibility in the Cloud
it does not allow users to access system state and it only supports Managed DBMS services want to allow users to create extensions,
one interface for writing extensions. This trade-o� is important to but they do not want to compromise the integrity and security of
consider because it determines the API that a DBMS exposes to their systems. This is problematic, especially for PostgreSQL, since
extension developers and the possible extensions. For example, most extensions can expose low-level access to the host machine (e.g.,
of SQLite’s extensions are UDFs, but the extensions for PostgreSQL, �le system, remote shell).

1972
 There are di�erent strategies to deal with this problem. The Since then, several works have proposed new types of DBMS
�rst is to modify the DBMS to introduce a new admin role with extensibility. For example, Umbra proposed user-de�ned operators
reduced permissions for installing extensions. For example, when a (UDOs) to support custom operations on UDTs [90]. Second, a few
user installs an extension in AWS RDS PostgreSQL [20], the DBMS recent works [129, 146, 147] have argued that the databases commu-
switches to an administrator role with unique permissions (e.g., nity should prioritize composability, which refers to building new
no �le system access) to add an extension. The second option is systems from a collection of its naturally well-de�ned components.
to modify the source code of allowed extensions to avoid these Both extensibility and composability argue for reusable, customiz-
problems. Google Cloud SQL [33] allows a regular user to create an able components within DBMSs. Unlike extensibility, composability
extension, which prevents escalation issues but is risky because it argues that the DBMS should consist of these components.
means regular users own extension catalog tables. For instance, a Operating System Extensibility: Understanding OS extensi-
user install a trigger on a pg_cron [73] catalog table and then wait bility is helpful because we can apply existing terminology, tech-
for the background worker with full administrative permissions to niques, and support mechanisms to categorize and analyze data-
write to that table and then execute the trigger. However, Google’s base system extensibility. Linux’s extensions [9] are shared objects
developers modi�ed pg_cron to prevent this from happening. Both written in C, while MacOS [21] provides a user-space API. Safer
approaches are laborious and error-prone; a better approach is to versions of extensibility that use sandboxing, veri�cation, type-safe
use a sandbox to reduce the exposure of the DBMS to such attacks. languages, and isolation techniques have been implemented suc-
cessfully in OSs [15, 123, 132, 140, 155]. These e�orts introduce
6.5 API Lessons many valuable ideas for safe, reliable extensibility frameworks. In
Our correlation analysis shows that extensions relying on coarse- the future, it may be helpful to apply the ideas of user-space exten-
grained hooks have higher compatibility failure rates. However, sions, sandboxing, formal extensibility frameworks, crash recovery,
the extensions using these hooks often add relatively simple func- and user-controlled research management to DBMS extensibility.
tionality, such as statistics collection. The DBMS should expose Browser Extensibility: There are ⇠130,000 Google Chrome
more �ne-grained hooks for common scenarios that do not carry extensions [130] and ⇠44,000 Mozilla Firefox extensions [32]. As
the compatibility risks identi�ed in Section 5.4. a result, security is a signi�cant focus in browser extensibility re-
PostgreSQL extensions copy code when they need to process in- search [121, 139, 156, 157]. Both Chrome [23, 121] and Firefox [44]
ternal data structures that the extension API permits them to access. support security features for extensions. Applying the lessons
The DBMS gives extensions a lot of responsibility to manage the learned to ensure safety in browser extensions is highly relevant to
system’s internal state (e.g., overriding core DBMS functions) but developing security measures for DBMS extensions.
without the necessary capability to do so (e.g., internal helper/API Feature Interactions: In software engineering, feature interac-
functions to modify these internal data structures). Therefore, de- tions research [138, 141, 150] focuses on understanding how two
velopers copy code to use and modify these data structures. Other di�erent features in a software system modify each other’s behavior.
problems occur when extensions rely on the representations of a Such research is relevant to DBMS extensibility because one can
DBMS’s internal objects, but those objects change in a new DBMS represent extensions as features in a system. This means applying
version (e.g., adding a new �eld to a struct) [149]. PostgreSQL is these results to DBMSs and using static and dynamic analysis to
designed to be extensible, and this is commendable. However, it make extension development easier is possible.
is a beautiful monstrosity because extensions can do essentially
anything in PostgreSQL. 8 CONCLUSION
Lastly, PostgreSQL makes building and testing extensions rela- This paper presented an evaluation of modern DBMS extensibility.
tively easy via its tooling. This partly explains why it has a more We �rst provided an overview of the major DBMS extensibility
extensive ecosystem than MySQL and MariaDB, even though they types and then expounded on �ve implementation considerations
have similar extensibility features. However, PostgreSQL lacks for extensions: (1) integration interfaces, (2) state modi�cation meth-
an authoritative platform for publishing extensions. In contrast, ods, (3) protection mechanisms, (4) supporting components, and (5)
DuckDB maintainers provide a platform for community extensions. developer APIs. We examined six open-source DBMSs and showed
Given the success of package managers for programming languages how their extension implementations di�er. We then performed a
(e.g., Rust [102], Python [92], JavaScript [54]), every DBMS should comprehensive analysis of PostgreSQL’s extensibility ecosystem.
strive to have an e�ective management tool for extensions. Such a To help with this analysis, we developed a toolkit that automat-
platform can also address quality concerns by recompiling exten- ically deploys and tests extensions. Our results demonstrate the
sions for new patch releases and running cross-extension tests. challenges in trading o� DBMS safety for extension �exibility. This
work highlights existing problems of DBMS extensibility and moti-
7 RELATED WORK vates future research on improving this critical capability.
We now discuss prior work on extensibility across system �elds.
DBMS Extensibility: One of the �rst studies on DBMS exten-
ACKNOWLEDGMENTS
sibility from the early 1990s examined emerging frameworks for The authors would like to thank the database extensions commu-
building DBMSs [125]. This study considers extensible DBMSs [122, nity for their support and feedback on this work. Particularly, we
126, 144, 148, 154] and identi�es three extensibility types: (1) user are very grateful to everyone who interacted with our talk at the
interface, (2) query processing, and (3) storage extensions. PostgreSQL Development Conference 2024!

1973
REFERENCES [36] 2024. Logical Decoding Concepts. Retrieved 2025-04-04 from https://www.
[1] 2003. PostgreSQL v7.4.0 Release Notes. Retrieved 2025-04-04 from https://www. postgresql.org/docs/current/logicaldecoding-explanation.html
postgresql.org/docs/release/7.4.0/ [37] 2024. MariaDB. Retrieved 2025-04-04 from https://mariadb.com/docs/server/
[2] 2005. PostgreSQL v8.1.23 Documentation: Appendix E. Release Notes. Retrieved ref/cs10.4/
2025-04-04 from https://www.postgresql.org/docs/8.1/release-8-1.html [38] 2024. MariaDB: ColumnStore Engine. Retrieved 2025-04-04 from https://mariadb.
[3] 2008. Oracle v8 Release Notes. Retrieved 2025-04-04 from https://www.orafaq. com/docs/columnstore/
com/wiki/Oracle_8 [39] 2024. MariaDB: Mroonga. Retrieved 2025-04-04 from https://mariadb.com/kb/
[4] 2013. PostgreSQL: pg_autovacuum. Retrieved 2025-04-04 from https://www. en/mroonga/
postgresql.org/docs/8.3/catalog-pg-autovacuum.html [40] 2024. MariaDB: Package Repository Setup and Usage. Retrieved 2025-04-04 from
[5] 2016. Oracle v7 Release Notes. Retrieved 2025-04-04 from https://www.orafaq. https://mariadb.com/kb/en/mariadb-package-repository-setup-and-usage/
com/wiki/Oracle_7 [41] 2024. mariadb-plugin. Retrieved 2025-04-04 from https://mariadb.com/kb/en/
[6] 2019. MariaDB: UUID Data Type. Retrieved 2025-04-04 from https://mariadb. mariadb-plugin/
com/kb/en/mariadb-plugin/ [42] 2024. MariaDB: S3 Storage Engine. Retrieved 2025-04-04 from https://mariadb.
[7] 2019. MySQL: CVE-2019-19959. Retrieved 2025-04-04 from https://nvd.nist.gov/ com/kb/en/s3-storage-engine/
vuln/detail/CVE-2019-19959 [43] 2024. Microsoft SQL Server. Retrieved 2025-04-04 from https://www.microsoft.
[8] 2019. SQL Server: User-de�ned Functions. Retrieved 2025-04-04 from com/en-us/sql-server
https://learn.microsoft.com/en-us/archive/msdn-magazine/2003/november/ [44] 2024. Mozilla Wiki: Security/Sandbox. Retrieved 2025-04-04 from https://wiki.
data-points-sql-server-user-de�ned-functions mozilla.org/Security/Sandbox
[9] 2020. The Linux Documentation Project. Retrieved 2025-04-04 from https: [45] 2024. MySQL. Retrieved 2025-04-04 from http://www.mysql.com
//tldp.org/ [46] 2024. MySQL: CVE-2024-20985. Retrieved 2025-04-04 from https://nvd.nist.gov/
[10] 2020. MySQL: CVE-2020-13630. Retrieved 2025-04-04 from https://nvd.nist.gov/ vuln/detail/CVE-2024-20985
vuln/detail/CVE-2020-13630 [47] 2024. MySQL: FEDERATED Storage Engine. Retrieved 2025-04-04 from https:
[11] 2020. PostgreSQL: CVE-2020-14350. Retrieved 2025-04-04 from https://www. //dev.mysql.com/doc/refman/8.0/en/federated-storage-engine.html
postgresql.org/support/security/CVE-2020-14350/ [48] 2024. MySQL: Introduction to InnoDB. Retrieved 2025-04-04 from https://dev.
[12] 2022. MySQL: CVE-2022-21454. Retrieved 2025-04-04 from https://nvd.nist.gov/ mysql.com/doc/refman/8.0/en/innodb-introduction.html
vuln/detail/CVE-2022-21454 [49] 2024. MySQL: MEMORY Storage Engine. Retrieved 2025-04-04 from https:
[13] 2022. PostgreSQL: CVE-2022-2625. Retrieved 2025-04-04 from https://www. //dev.mysql.com/doc/refman/8.0/en/memory-storage-engine.html
postgresql.org/support/security/CVE-2022-2625/ [50] 2024. MySQL: Password Validation Component. Retrieved 2025-04-04 from
[14] 2022. Redis: Lua scripts can be manipulated to overcome ACL rules. Retrieved 2025- https://dev.mysql.com/doc/refman/8.3/en/validate-password.html
04-04 from https://github.com/redis/redis/security/advisories/GHSA-647m- [51] 2024. MySQL: Query Job Queue. Retrieved 2025-04-04 from https://github.com/
2wmq-qmvq adrpar/mysql_query_queue
[15] 2023. eBPF Documentation. Retrieved 2025-04-04 from https://ebpf.io/what-is- [52] 2024. MySQL: Rewriter Query Rewrite Plugin Reference. Retrieved 2025-04-04
ebpf/ from https://dev.mysql.com/doc/refman/8.0/en/rewriter-query-rewrite-plugin-
[16] 2023. PostgreSQL: Contrib module. Retrieved 2025-04-04 from https://pgpedia. reference.html
info/c/contrib-module.html [53] 2024. mysql_vss. Retrieved 2025-04-04 from https://github.com/stephenc222/
[17] 2023. PostgreSQL: CVE-2023-39417. Retrieved 2025-04-04 from https://www. mysql_vss
postgresql.org/support/security/CVE-2023-39417/ [54] 2024. npm. Retrieved 2025-04-04 from https://www.npmjs.com/
[18] 2023. PostgreSQL v15.3 Release Notes. Retrieved 2025-04-04 from https://www. [55] 2024. Oracle. Retrieved 2025-04-04 from https://www.oracle.com
postgresql.org/docs/release/15.3/ [56] 2024. ParadeDB. Retrieved 2025-04-04 from https://www.paradedb.com/
[19] 2023. SQL Server: CLR User-De�ned Types. Retrieved 2025-04-04 from [57] 2024. pg_regress. Retrieved 2025-04-04 from https://github.com/postgres/
https://learn.microsoft.com/en-us/sql/relational-databases/clr-integration- postgres/blob/master/src/test/regress/pg_regress.c
database-objects-user-de�ned-types/clr-user-de�ned-types?view=sql- [58] 2024. pgvector. Retrieved 2025-04-04 from https://github.com/pgvector/
server-ver16 pgvector
[20] 2024. Amazon RDS for PostgreSQL. Retrieved 2025-04-04 from https://aws. [59] 2024. PGXN: PostgreSQL Extension Network. Retrieved 2025-04-04 from https:
amazon.com/rds/postgresql/ //pgxn.org/
[21] 2024. Apple OS X System Extensions. Retrieved 2025-04-04 from https: [60] 2024. pgxs. Retrieved 2025-04-04 from https://www.postgresql.org/docs/
//developer.apple.com/documentation/systemextensions current/extend-pgxs.html
[22] 2024. Azure Database for PostgreSQL. Retrieved 2025-04-04 from https://azure. [61] 2024. plPro�ler. Retrieved 2025-04-04 from https://github.com/bigsql/plpro�ler
microsoft.com/en-us/products/postgresql [62] 2024. PL/Rust. Retrieved 2025-04-04 from https://github.com/tcdi/plrust
[23] 2024. Chrome Extensions: Manifest - Sandbox. Retrieved 2025-04-04 from [63] 2024. PLV8. Retrieved 2025-04-04 from https://github.com/plv8/plv8
https://developer.chrome.com/docs/extensions/reference/manifest/sandbox [64] 2024. PostGIS. Retrieved 2025-04-04 from https://postgis.net/
[24] 2024. Citus. Retrieved 2025-04-04 from https://github.com/citusdata/citus [65] 2024. PostgreSQL Benchmark (pgbench). Retrieved 2025-04-04 from https:
[25] 2024. Citus Columnar. Retrieved 2025-04-04 from https://github.com/citusdata/ //www.postgresql.org/docs/current/pgbench.html
citus/tree/main/src/backend/columnar [66] 2024. PostgreSQL: CREATE EXTENSION. Retrieved 2025-04-04 from https:
[26] 2024. Create hooks to let a loadable plugin monitor (or even replace) the planner. //www.postgresql.org/docs/15/sql-createextension.html
Retrieved 2025-04-04 from https://git.postgresql.org/gitweb/?p=postgresql.git; [67] 2024. PostgreSQL: GiST and GIN Index Types. Retrieved 2025-04-04 from
a=commit;h=604�d280b955100e5fc24649ee4d42a6f3ebf35 https://www.postgresql.org/docs/9.1/textsearch-indexes.html
[27] 2024. DuckDB: Community Extensions Repository. Retrieved 2025-04-04 from [68] 2024. PostgreSQL Global Development Group. Retrieved 2025-04-04 from
https://github.com/duckdb/community-extensions https://www.postgresql.org/developer/core/
[28] 2024. DuckDB: Postgres Scanner. Retrieved 2025-04-04 from https://github.com/ [69] 2024. PostgreSQL: isn. Retrieved 2025-04-04 from https://www.postgresql.org/
duckdb/postgres_scanner docs/current/isn.html
[29] 2024. DuckDB: SQLite Scanner. Retrieved 2025-04-04 from https://github.com/ [70] 2024. PostgreSQL: lsm3. Retrieved 2025-04-04 from https://github.com/
duckdb/sqlite_scanner postgrespro/lsm3
[30] 2024. ElasticSearch. Retrieved 2025-04-04 from https://www.elastic.co/ [71] 2024. PostgreSQL: passwordcheck. Retrieved 2025-04-04 from https://www.
elasticsearch postgresql.org/docs/current/passwordcheck.html
[31] 2024. Finding duplicated code with CPD. Retrieved 2025-04-04 from https: [72] 2024. PostgreSQL: pg_bigm. Retrieved 2025-04-04 from https://github.com/
//pmd.github.io/pmd/pmd_userdocs_cpd pgbigm/pg_bigm
[32] 2024. Firefox Browser Add-Ons. Retrieved 2025-04-04 from https://addons. [73] 2024. PostgreSQL: pg_cron. Retrieved 2025-04-04 from https://github.com/
mozilla.org/en-US/�refox/search/?type=extension citusdata/pg_cron
[33] 2024. Google Cloud SQL. Retrieved 2025-04-04 from https://cloud.google.com/ [74] 2024. PostgreSQL: pg_hint_plan. Retrieved 2025-04-04 from https://github.com/
sql/postgresql ossc-db/pg_hint_plan
[34] 2024. Kerberos Pluggable Authentication. Retrieved 2025-04-04 from [75] 2024. PostgreSQL: pg_ivm. Retrieved 2025-04-04 from https://github.com/
https://dev.mysql.com/doc/mysql-security-excerpt/8.0/en/kerberos- sraoss/pg_ivm
pluggable-authentication.html [76] 2024. PostgreSQL: pgpointcloud. Retrieved 2025-04-04 from https://github.com/
[35] 2024. logerrors. Retrieved 2025-04-04 from https://github.com/munakoiso/ pgpointcloud/pointcloud
logerrors [77] 2024. PostgreSQL: pg_queryid. Retrieved 2025-04-04 from https://github.com/
rjuju/pg_queryid

1974
 [78] 2024. PostgreSQL: pg_repack. Retrieved 2025-04-04 from https://github.com/ [120] Sam Ansmink. 2024. DuckDB – C API Extensions. Retrieved 2025-04-04 from
reorg/pg_repack https://github.com/duckdb/duckdb/pull/12682
[79] 2024. PostgreSQL: pgsentinel. Retrieved 2025-04-04 from https://github.com/ [121] Adam Barth, Adrienne Porter Felt, Prateek Saxena, and Aaron Boodman. 2010.
pgsentinel/pgsentinel Protecting Browsers from Extension Vulnerabilities. In Network and Distributed
[80] 2024. PostgreSQL: pg_show_plan. Retrieved 2025-04-04 from https://github. System Security Symposium.
com/cybertec-postgresql/pg_show_plans [122] D.S. Batoory, J.R. Barnett, J.F. Garza, K.P. Smith, K. Tsukuda, B.C. Twichell,
[81] 2024. PostgreSQL: pgstatkcache. Retrieved 2025-04-04 from https://github.com/ and T.E. Wise. 1988. GENESIS: an extensible database management system.
powa-team/pg_stat_kcache IEEE Transactions on Software Engineering 14, 11 (1988), 1711–1730. https:
[82] 2024. PostgreSQL: pg_stat_monitor. Retrieved 2025-04-04 from https://github. //doi.org/10.1109/32.9057
com/percona/pg_stat_monitor [123] B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. E. Fiuczynski, D. Becker,
[83] 2024. PostgreSQL: pg_stat_statements. Retrieved 2025-04-04 from https://www. C. Chambers, and S. Eggers. 1995. Extensibility Safety and Performance in
postgresql.org/docs/current/pgstatstatements.html the SPIN Operating System. SIGOPS Oper. Syst. Rev. 29, 5 (dec 1995), 267–283.
[84] 2024. PostgreSQL: postgres_fdw. Retrieved 2025-04-04 from https://www. https://doi.org/10.1145/224057.224077
postgresql.org/docs/current/postgres-fdw.html [124] Fuyuan Cao, Jiye Liang, and Liang Bai. 2009. A new initialization method
[85] 2024. PostgreSQL: Pre�x Range Module. Retrieved 2025-04-04 from https: for categorical data clustering. Expert Syst. Appl. 36 (09 2009), 10223–10228.
//github.com/dimitri/pre�x https://doi.org/10.1016/j.eswa.2009.01.060
[86] 2024. PostgreSQL: Rust Extensions Framework (pgrx). Retrieved 2025-04-04 [125] Michael Carey and Laura Haas. 1990. Extensible Database Management Systems.
from https://docs.rs/pgrx/latest/pgrx/ SIGMOD Rec. 19, 4 (dec 1990), 54–60. https://doi.org/10.1145/122058.122064
[87] 2024. PostgreSQL: SECURITY LABEL. Retrieved 2025-04-04 from https://www. [126] Michael J. Carey, David J. DeWitt, Daniel Frank, Goetz Graefe, Joel E. Richardson,
postgresql.org/docs/current/sql-security-label.html Eugene J. Shekita, and M. Muralikrlshna. 1991. The Architecture of the EXODUS
[88] 2024. PostgreSQL: test_decoding. Retrieved 2025-04-04 from https://www. Extensible DBMS. 231–256. https://doi.org/10.1007/978-3-642-84374-7_15
postgresql.org/docs/current/test-decoding.html [127] Claude. 2024. Generating small UDT datasets. Retrieved 2025-04-04 from
[89] 2024. PostgreSQL: Trusted Language Extensions. Retrieved 2025-04-04 from https://claude.ai/chat
https://github.com/aws/pg_tle [128] Umur Cubukcu, Ozgun Erdogan, Sumedh Pathak, Sudhakar Sannakkayala, and
[90] 2024. PostgreSQL: User-De�ned Operators. Retrieved 2025-04-04 from https: Marco Slot. 2021. Citus: Distributed PostgreSQL for Data-Intensive Applications.
//www.postgresql.org/docs/current/xoper.html In Proceedings of the 2021 International Conference on Management of Data
[91] 2024. Provide a function hook to let plug-ins get control around ExecutorRun. (SIGMOD ’21). 2490–2502. https://doi.org/10.1145/3448016.3457551
Retrieved 2025-04-04 from https://git.postgresql.org/gitweb/?p=postgresql.git; [129] Voltron Data. 2023. The Composable Codex. Retrieved 2025-04-04 from https:
a=commit;h=6cc88f0af5b12b22ce1826a26b1a953c434bd165 //voltrondata.com/codex
[92] 2024. Python PIP. Retrieved 2025-04-04 from https://pypi.org/project/pip/ [130] Brian Dean. 2024. Google Chrome Statistics. Retrieved 2025-04-04 from https:
[93] 2024. Redis. Retrieved 2025-04-04 from https://redis.io/ //backlinko.com/chrome-users
[94] 2024. Redis Adopts Dual Source-Available Licensing. Retrieved 2025-04-04 from [131] Siying Dong, Andrew Kryczka, Yanqin Jin, and Michael Stumm. 2021. RocksDB:
https://redis.io/blog/redis-adopts-dual-source-available-licensing/ Evolution of Development Priorities in a Key-value Store Serving Large-scale
[95] 2024. Redis: Commands. Retrieved 2025-04-04 from https://redis.io/docs/latest/ Applications. ACM Trans. Storage 17, 4, Article 26 (Oct. 2021), 32 pages. https:
develop/reference/modules/ //doi.org/10.1145/3483840
[96] 2024. Redis Modules (Archived from 2024-04-06). Retrieved 2024-04-06 from https: [132] D. R. Engler, M. F. Kaashoek, and J. O’Toole. 1995. Exokernel: An Operating
//web.archive.org/web/20240406192236/https://redis.io/resources/modules/ System Architecture for Application-Level Resource Management. In Proceed-
[97] 2024. Redis Modules Software Development Kit. Retrieved 2025-04-04 from ings of the Fifteenth ACM Symposium on Operating Systems Principles (SOSP ’95).
https://github.com/RedisLabsModules/RedisModulesSDK 251–266. https://doi.org/10.1145/224056.224076
[98] 2024. Redis: pam_auth. Retrieved 2025-04-04 from https://github.com/ [133] Joseph M Hellerstein, Je�rey F Naughton, and Avi Pfe�er. 1995. Generalized
RedisLabsModules/pam_auth Search Trees for Database Systems. In Proceedings of the 21th International
[99] 2024. RediSearch. Retrieved 2025-04-04 from https://github.com/RediSearch/ Conference on Very Large Data Bases. 562–573.
RediSearch [134] Dongxu Huang, Qi Liu, Qiu Cui, Zhuhe Fang, Xiaoyu Ma, Fei Xu, Li Shen, Liu
[100] 2024. RedisGraph. Retrieved 2025-04-04 from https://github.com/RedisGraph/ Tang, Yuxing Zhou, Menglong Huang, Wan Wei, Cong Liu, Jian Zhang, Jianjun
RedisGraph Li, Xuelian Wu, Lingyu Song, Ruoxi Sun, Shuaipeng Yu, Lei Zhao, Nicholas
[101] 2024. RUM - RUM access method. Retrieved 2025-04-04 from https://github. Cameron, Liquan Pei, and Xin Tang. 2020. TiDB: a Raft-based HTAP database.
com/postgrespro/rum Proc. VLDB Endow. 13, 12 (Aug. 2020), 3072–3084. https://doi.org/10.14778/
[102] 2024. Rust Cargo. Retrieved 2025-04-04 from https://github.com/rust-lang/cargo 3415478.3415535
[103] 2024. Some infrastructure changes for the upcoming auto-explain contrib module:. [135] IBM. 2000. DB2 Universal Database for OS/390 IBM Release Planning Guide
Retrieved 2025-04-04 from https://git.postgresql.org/gitweb/?p=postgresql.git; Version 6. International Business Machines Corporation.
a=commit;h=cd35e9d7468e8f86dd5a7d928707f4ba8cdae44d [136] International Organization for Standardization 1996. ISO/IEC 9075-4:1996 (1st
[104] 2024. SQLite. Retrieved 2025-04-04 from https://www.sqlite.org/index.html ed.). International Organization for Standardization.
[105] 2024. SQLite: Encryption Extension. Retrieved 2025-04-04 from https://www. [137] International Organization for Standardization 1999. ISO/IEC 9075-2:1999 (1st
sqlite.org/see/doc/trunk/www/readme.wiki ed.). International Organization for Standardization.
[106] 2024. SQLite Extensions. Retrieved 2025-04-04 from https://github.com/riyaz- [138] Sergiy S. Kolesnikov, Norbert Siegmund, Christian Kästner, and Sven Apel.
ali/sqlite 2017. On the Relation of External and Internal Feature Interactions: A Case Study.
[107] 2024. SQLite: os_unix. Retrieved 2025-04-04 from https://sqlite.org/src/�le? Technical Report 1712.07440. arXiv. https://arxiv.org/abs/1712.07440
name=src/os_unix.c&ci=trunk [139] David M Martin Jr, Richard M Smith, Michael Brittain, Ivan Fetch, and Hailin
[108] 2024. SQLite: sqlean. Retrieved 2025-04-04 from https://github.com/nalgeon/ Wu. 2001. The privacy practices of web browser extensions. Commun. ACM 44,
sqlean 2 (2001), 45–50.
[109] 2024. SQLite: sqlite-loadable-rs. Retrieved 2025-04-04 from https://github.com/ [140] Steven McCanne and Van Jacobson. 1993. The BSD Packet Filter: A New
asg017/sqlite-loadable-rs Architecture for User-Level Packet Capture. In Proceedings of the USENIX Winter
[110] 2024. SQLite: sqlite-vss. Retrieved 2025-04-04 from https://github.com/asg017/ 1993 Conference Proceedings on USENIX Winter 1993 Conference Proceedings (San
sqlite-vss Diego, California) (USENIX’93). USENIX Association, USA, 2.
[111] 2024. SQLite: sqlite3ext.h. Retrieved 2025-04-04 from https://www2.sqlite. [141] Jens Meinicke, Chu-Pan Wong, Christian Kästner, Thomas Thüm, and Gunter
org/src/�le?name=src/sqlite3ext.h Saake. 2016. On Essential Con�guration Complexity: Measuring Interactions
[112] 2024. TimescaleDB. Retrieved 2025-04-04 from https://github.com/timescale/ in Highly-Con�gurable Systems (ASE ’16). 483–494. https://doi.org/10.1145/
timescaledb 2970276.2970322
[113] 2024. Vector Similarity Search. Retrieved 2025-04-04 from https://github.com/ [142] Hannes Mühleisen and Mark Raasveldt. 2025. Runtime-Extensible Parsers.
duckdb/duckdb_vss In 15th Annual Conference on Innovative Data Systems Research (CIDR ’25),
[114] 2024. wal2json. Retrieved 2025-04-04 from https://github.com/eulerto/wal2json Amsterdam, The Netherlands, January 19-22, 2025. www.cidrdb.org. https:
[115] 2024. zeeSQL. Retrieved 2025-04-04 from https://zeesql.com //duckdb.org/pdf/CIDR2025-muehleisen-raasveldt-extensible-parsers.pdf
[116] 2025. Database Extensions Analyzer. Retrieved 2025-04-04 from https://github. [143] James Ong, Dennis Fogg, and Michael Stonebraker. 1983. Implementation of
com/cmu-db/ext-analyzer data abstraction in the relational database system INGRES. SIGMOD Rec. 14, 1
[117] 2025. DuckDB. Retrieved 2025-04-04 from https://duckdb.org/ (sep 1983), 1–14. https://doi.org/10.1145/984540.984541
[118] 2025. Oracle: Introduction to Oracle Database Extensions for .NET. Retrieved 2025- [144] Sylvia L. Osborn and T. E. Heaven. 1986. The Design of a Relational Database
04-04 from https://docs.oracle.com/cd/E11882_01/win.112/e17724/intro.htm System with Abstract Data Types for Domains. ACM Trans. Database Syst. 11,
[119] 2025. PostgreSQL. Retrieved 2025-04-04 from https://www.postgresql.org 3 (aug 1986), 357–373. https://doi.org/10.1145/6314.6461

1975
[145] Sasha Pachev. 2007. Understanding MySQL Internals. O’Reilly Media, Inc., IEEE Computer Society, 2–11. https://doi.org/10.1109/ICDE.2005.1
Chapter 1. MySQL History and Architecture. [153] Michael Stonebraker, Gerald Held, Eugene Wong, and Peter Kreps. 1976. The
[146] Pedro Pedreira, Orri Erling, Konstantinos Karanasos, Scott Schneider, Wes design and implementation of INGRES. ACM Trans. Database Syst. 1, 3 (sep
McKinney, Satya R Valluri, Mohamed Zait, and Jacques Nadeau. 2023. The 1976), 189–222. https://doi.org/10.1145/320473.320476
Composable Data Management System Manifesto. Proceedings of the VLDB [154] Michael Stonebraker and Lawrence A. Rowe. 1986. The Design of POSTGRES. In
Endowment 16, 10 (2023), 2679–2685. Proceedings of the 1986 ACM SIGMOD International Conference on Management
[147] Danica Porobic. 2019. Revisiting RISC-style Data Management System Design.. of Data (SIGMOD ’86). 340–355. https://doi.org/10.1145/16894.16888
In CIDR. [155] Michael M. Swift, Steven Martin, Henry M. Levy, and Susan J. Eggers. 2002.
[148] P. Schwarz, W. Chang, J. C. Freytag, G. Lohman, J. McPherson, C. Mohan, and H. Nooks: An Architecture for Reliable Device Drivers. In Proceedings of the 10th
Pirahesh. 1986. Extensibility in the Starburst Database System. In Proceedings Workshop on ACM SIGOPS European Workshop (EW 10). 102–107. https://doi.
on the 1986 International Workshop on Object-Oriented Database Systems (OODS org/10.1145/1133373.1133393
’86). 85–92. [156] Mike Ter Louw, Jin Soon Lim, and Venkat N Venkatakrishnan. 2007. Extensible
[149] Marco Slot. 2024. . Retrieved 2025-04-04 from https://twitter.com/marcoslot/ web browser security. In Detection of Intrusions and Malware, and Vulnerability
status/1858132850383421570 Assessment: 4th International Conference, DIMVA 2007 Lucerne, Switzerland, July
[150] Larissa Soares, Jens Meinicke, Sarah Nadi, Christian Kästner, and Eduardo 12-13, 2007 Proceedings 4. Springer, 1–19.
Almeida. 2018. VarXplorer: Lightweight Process for Dynamic Analysis of [157] Mike Ter Louw, Jin Soon Lim, and Venkat N Venkatakrishnan. 2008. Enhancing
Feature Interactions. In VAMOS 2018: Proceedings of the 12th International web browser security against malware extensions. Journal in Computer Virology
Workshop on Variability Modelling of Software-Intensive Systems. 59–66. https: 4 (2008), 179–195.
//doi.org/10.1145/3168365.3168376 [158] Wikipedia. 2024. Comparison of MySQL database engines — Wikipedia, The
[151] Michael Stonebraker. 2023. Personal Correspondence. Free Encyclopedia. Retrieved 2025-04-04 from https://en.wikipedia.org/wiki/
[152] Michael Stonebraker and Ugur Çetintemel. 2005. "One Size Fits All": An Idea Comparison_of_MySQL_database_engines
Whose Time Has Come and Gone (Abstract). In Proceedings of the 21st Interna-
tional Conference on Data Engineering, ICDE 2005, 5-8 April 2005, Tokyo, Japan.

1976