DuckDB Extensions Vocabulary: English for In-Process Analytics Discussions

DuckDB has become a favourite tool among data scientists and analytics engineers for its speed, simplicity, and surprisingly rich extension ecosystem. If you work with DuckDB in team settings — code reviews, documentation, or technical discussions — knowing the right English vocabulary will help you communicate precisely. This guide covers the core terms and the collocations that surround them.

Core Vocabulary

Extension A loadable plugin that adds new functionality to DuckDB, such as support for a file format, a remote filesystem, or a geospatial functions library. Extensions can be installed and loaded at runtime.

“We added the spatial extension to support the geographic distance calculations — it ships with PostGIS-compatible functions.”

Autoload A DuckDB behaviour where certain well-known extensions are automatically loaded when a relevant function or file type is referenced, without requiring an explicit LOAD statement.

“DuckDB autoloaded the httpfs extension when we ran the query against the S3 URL, so we didn’t need to install it manually.”

Spatial extension A DuckDB extension that provides geospatial data types and functions, including support for reading shapefiles and performing geometric operations.

“Once we loaded the spatial extension, we could query the GeoJSON files directly with standard SQL and spatial predicates.”

httpfs An extension that enables DuckDB to read files from remote HTTP or S3-compatible endpoints directly in SQL queries, without downloading files first.

“With httpfs, our analysts can query Parquet files sitting in S3 as if they were local tables — no ETL step needed.”

Iceberg extension A DuckDB extension that adds native support for reading Apache Iceberg tables, including metadata scanning and snapshot-based time travel.

“We installed the Iceberg extension so the analytics team can query our data lake directly without going through Spark.”

Community extensions vs core extensions Core extensions are maintained by the DuckDB team and ship with guaranteed compatibility. Community extensions are contributed by third parties and may have looser version compatibility guarantees.

“Before you add that community extension to the pipeline, check the compatibility matrix — community extensions don’t always follow the same release cadence as core ones.”

ATTACH statement A DuckDB SQL command that connects an external database file — another DuckDB file, a SQLite database, or a remote source — to the current session, allowing cross-database queries.

“We ATTACH the production DuckDB file as read-only and join it against our local staging data to compare results.”

In-process database A database engine that runs inside the host process rather than as a separate server. DuckDB is in-process, meaning it runs inside your Python script or application without a network connection or separate daemon.

“The great thing about an in-process database is that there’s zero serialisation overhead — DuckDB reads your Pandas dataframe directly from memory.”

Persistent vs in-memory mode DuckDB can run with data stored on disk (persistent mode) or entirely in RAM (in-memory mode). In-memory mode is faster for ephemeral analysis but loses all data when the session ends.

“For our CI pipeline, we use in-memory mode so the test database is automatically discarded — no cleanup step needed.”

Key Collocations

• install and load an extension — “To use httpfs, you need to install and load the extension first — INSTALL httpfs; LOAD httpfs.”
• attach a remote database — “We can attach a remote database over the S3 endpoint and query it alongside local tables in the same SQL statement.”
• query remote files — “DuckDB lets you query remote files on S3 directly using the httpfs extension — no local copy required.”
• scan a Parquet file — “The query scans a Parquet file of 4 billion rows and returns results in under 10 seconds on a laptop.”
• persist to disk — “For long-running analysis sessions, we persist to disk so we can resume the next day without re-processing the source data.”
• run in-memory — “Unit tests for our data transformations run in-memory with a seed dataset — fast and isolated.”

Using This Vocabulary in Discussions

One of the most common DuckDB topics in team discussions is the trade-off between persistent and in-memory mode. A typical exchange might sound like: “Do we actually need to persist to disk here, or can we run in-memory and regenerate from source if needed? The dataset is only 2 GB.” Using these terms precisely — rather than “save to a file” or “keep it in RAM” — shows familiarity with DuckDB’s architecture.

When discussing extensions, English speakers frequently use the pair “install and load” together, because these are two separate steps in DuckDB. You install an extension once (it downloads and caches it), and you load it each session. Knowing this distinction prevents confusion when someone says “I installed httpfs but it’s not working” — the answer is usually “did you also load it?”

The verb “attach” has a specific meaning in DuckDB that is different from its everyday English usage. In daily English, “attach” usually means to fasten something to something else. In DuckDB, you attach a database to the current session — similar to mounting a drive. If you need to explain this to a new team member, you might say: “ATTACH is how we connect a second database file so we can query both in the same SQL.”

Common Mistakes to Avoid

A common source of confusion is mixing up extension and plugin in DuckDB contexts. While “plugin” is a general term, the DuckDB community consistently uses “extension.” Using “plugin” is understandable, but it signals that you may be borrowing from another ecosystem’s vocabulary.

Another frequent mistake is describing DuckDB as a “server database” or asking “what port does DuckDB run on?” DuckDB is an in-process database — there is no server, no port, and no connection string in the traditional sense. The correct framing is: “DuckDB runs inside your process.”

Practice Tip

Open DuckDB’s extension documentation and pick three extensions you haven’t used before. Write a short paragraph explaining what each one does and when you would use it, using the phrase “install and load” in at least one sentence. Then describe the difference between running in-memory versus persisting to disk in your own words — this is a question that commonly comes up when onboarding new team members.

In Practice: Navigating Nuance in Feedback

The term “undefined” – you’ll encounter it constantly in software development discussions. It’s more than just a programming error; it represents a broader challenge of conveying meaning clearly, particularly when dealing with feedback and requests. Let’s consider a scenario within a team at a mid-sized tech company, “Innovate Solutions.” Sarah, a junior developer, submitted a pull request to refactor the user authentication flow. During code review, Mark, a senior engineer, left a comment: “This section is undefined.”

Initially, Sarah felt immediately defensive. She’d spent hours on this, and she interpreted “undefined” as criticism of her work, perhaps implying it was fundamentally flawed. However, experienced developers often use “undefined” to signal a lack of clarity, not necessarily a problem with the code itself. It’s frequently used when someone doesn’t understand what is expected or why something is done in a particular way. It prompts further investigation rather than outright rejection. The key takeaway here isn’t Sarah’s immediate reaction, but how she responds to this feedback.

A productive response wouldn’t be, “I don’t understand what you mean!” Instead, Sarah could have replied via Slack: “Hi Mark, thanks for the review! When you say ‘undefined,’ I was wondering if you could elaborate on what specifically isn’t clear? Are you concerned about potential edge cases I haven’t addressed, or perhaps about the overall design decision?” This demonstrates a willingness to understand and collaborate. It shifts the conversation from a perceived judgment back to a shared goal of creating robust and maintainable code. Mark might then explain his concerns – perhaps he wanted assurance that all possible user input scenarios were handled gracefully, or that the refactoring aligned with Innovate Solutions’ broader security standards.

Furthermore, consider how this could be framed in a pull request description itself. Instead of simply stating “Refactored authentication flow,” Sarah could have written: “This PR introduces changes to the authentication flow, focusing on improved error handling and adherence to [Company Security Policy X]. I’ve added detailed comments documenting the rationale behind each change and identified potential edge cases that require further validation – areas I’d appreciate your feedback on to ensure they are fully ‘defined’ within this context.” The use of phrases like “adherence to,” “rationale,” and “potential edge cases” proactively addresses the type of concern raised by Mark, demonstrating a commitment to clear communication and shared understanding.