DuckDB: The Embedded Analytics Database

TL;DR
Introduction
What is DuckDB?
Why It Exists & How It Works
Key Features & Capabilities
Getting Started
Advanced Usage & Best Practices
Real-World Usage Patterns
Comparison with Alternatives
Limitations & Considerations
FAQ
The Embedded Analytics Sweet Spot

TL;DR

DuckDB is an embedded SQL database optimized for analytical workloads that runs directly within your application process, eliminating the need for separate database servers. It excels at fast columnar processing, can query files directly from cloud storage (CSV, Parquet, JSON), and provides zero-configuration deployment making it ideal for embedded analytics, ETL pipeline replacement, and powering dashboard APIs. While it offers exceptional performance for analytical queries through vectorized execution and intelligent compression, DuckDB has important limitations including memory management challenges, single-node architecture constraints, and concurrency restrictions that require careful consideration in production environments.

Introduction

When your web application starts processing gigabytes of user data for dashboards and reports, traditional row-based databases like PostgreSQL and MySQL begin to struggle. Complex analytical queries that should return results in milliseconds start taking seconds or even minutes. Your users notice the sluggish performance, and you're faced with a choice: build expensive data warehousing infrastructure or find a better approach to embedded analytics.

DuckDB solves this exact problem: an embedded SQL database designed specifically for analytical workloads that runs directly within your application process.

What is DuckDB?

DuckDB is an embedded SQL OLAP (Online Analytical Processing) database management system designed as "SQLite for analytics." Unlike traditional client-server databases, DuckDB runs in-process within your application with zero external dependencies, making it fundamentally different from systems like PostgreSQL or MySQL.

The core distinction lies in its optimization focus. While SQLite excels at transactional workloads (OLTP), DuckDB specializes in analytical queries over large datasets. According to DuckDB documentation, it's built as an "in-process SQL OLAP database management system" that eliminates the complexity of managing separate database servers.

Primary Use Cases for Full-Stack Developers:

DuckDB solves specific problems that full-stack developers encounter when building data-heavy applications:

Embedded Analytics: Adding analytical capabilities to applications without external database dependencies
ETL and Data Transformation: Replacing complex parsing code with SQL queries for data processing
Local Data Analysis: Fast analytical processing during development and testing phases
Direct File Querying: Processing CSV, Parquet, and JSON files directly from cloud storage without traditional ETL pipelines

Database Ecosystem Positioning:

DuckDB occupies a unique position in the database landscape. Where SQLite provides embedded transactional capabilities and PostgreSQL offers comprehensive general-purpose database features, DuckDB specifically targets the embedded analytics niche. It's not a replacement for your primary transactional database, but rather a complementary tool for analytical workloads within your existing application architecture.

Why It Exists & How It Works

Modern applications need fast analytical capabilities embedded directly within the application layer, without the operational overhead of managing separate analytical databases or data warehouses.

The Analytical Database Problem:

Traditional databases store data in rows, which works well for transactional operations like user registration or order processing. However, analytical queries typically need to process entire columns of data: calculating averages, sums, or filtering large datasets. Row-based storage forces the database to read unnecessary data and process it inefficiently.

DuckDB's Architectural Solution:

DuckDB addresses this through a columnar-vectorized execution engine. The research paper details how DuckDB uses a vectorized interpreted execution engine that processes data in fixed-size batches optimized for modern CPU architectures.

The system combines three key architectural elements:

Columnar Storage: Data is stored column-wise rather than row-wise, enabling better compression and allowing queries to read only required columns
Vectorized Processing: Operations are performed on batches of data (typically 1024-2048 items) that fit within CPU L1 cache, maximizing instruction throughput
Embedded Architecture: The database runs within your application process, eliminating network overhead and serialization costs

Key Features & Capabilities

Columnar Storage with Intelligent Compression

DuckDB's columnar storage architecture provides several critical optimizations according to Endjin's analysis. The columnar approach delivers significant performance benefits through several mechanisms:

Improved Compression: Similar data types within columns compress more efficiently than mixed row data, often achieving compression ratios of 3:1 or better
Column Pruning: Only required columns are read during query execution, dramatically reducing I/O requirements
Zone Map Acceleration: Min-max indexes enable entire row groups to be skipped during filtering operations

When you execute SELECT name, revenue FROM sales_data, DuckDB reads only the name and revenue columns. Queries like WHERE date >= '2024-01-01' can eliminate entire data segments without scanning them.

Vectorized Execution Engine

The vectorized execution engine processes data in small batches typically containing 1024-2048 items that fit within the CPU L1 cache. According to the performance guide, this approach "processes data in batches (vectors) to reduce CPU cycles per value."

Key performance optimizations include:

SIMD Operations: Single Instruction, Multiple Data operations allow the CPU to perform operations on multiple data elements simultaneously
Automatic Parallelization: DuckDB distributes work across all available CPU cores without requiring explicit configuration
Cache-Optimized Processing: Row-group-based threading with defaults of 122,880 rows per group ensures optimal CPU utilization

For operations like summing a column of integers, SIMD can provide 4-8x performance improvements over scalar operations.

Zero-Copy File Processing

One of DuckDB's most compelling features for full-stack developers is its ability to query files directly without importing them into the database first. This capability, called zero-copy processing, supports multiple file formats:

-- Query CSV files directly
SELECT AVG(sales_amount) FROM read_csv_auto('s3://bucket/sales_data.csv');

-- Process Parquet files from cloud storage
SELECT date, SUM(revenue) FROM read_parquet('gs://analytics/revenue/*.parquet')
GROUP BY date ORDER BY date;

-- Combine multiple formats in a single query
SELECT c.customer_name, SUM(s.amount)
FROM read_csv_auto('customers.csv') c
JOIN read_parquet('sales.parquet') s ON c.id = s.customer_id
GROUP BY c.customer_name;

Cloud Storage Integration

DuckDB provides native connectivity to major cloud storage platforms through its extension system. According to extension docs, developers can query data directly from:

AWS S3: SELECT * FROM 's3://bucket/path/file.parquet';
Google Cloud Storage: SELECT * FROM 'gcs://bucket/data/*.csv';
Azure Blob Storage: SELECT * FROM 'azure://container/data.json';

Authentication is handled through standard cloud SDK credentials, making integration with existing cloud infrastructure seamless.

Getting Started

DuckDB's zero-configuration setup makes it ideal for rapid prototyping and development. Let's walk through practical implementation examples for common full-stack development scenarios.

Installation Options

According to the installation guide, multiple installation pathways are available:

# Package managers
brew install duckdb          # macOS
winget install DuckDB.cli    # Windows

# Universal installer
curl https://install.duckdb.org | sh

# Language-specific installations
npm install duckdb           # Node.js
python -m pip install duckdb # Python

Basic Operations and Data Import

The MotherDuck tutorial demonstrates immediate SQL execution capabilities:

-- Start with simple operations
SELECT 42 AS answer;

-- Automatic schema detection for CSV files
CREATE TABLE user_events AS
SELECT * FROM read_csv_auto('path/to/events.csv');

-- Verify the import
DESCRIBE user_events;
SELECT COUNT(*) FROM user_events;

Node.js Integration for Web APIs

The Node.js client provides patterns for integrating DuckDB with Express.js applications:

const duckdb = require('duckdb');
const express = require('express');
const app = express();

// Create persistent connection
const db = new duckdb.Database('analytics.db');

// Analytics endpoint with real-time CSV processing
app.get('/api/analytics/daily-users', (req, res) => {
  const query = `
    SELECT DATE_TRUNC('day', timestamp) as date,
           COUNT(DISTINCT user_id) as daily_active_users
    FROM read_csv_auto('user_events.csv')
    WHERE timestamp >= NOW() - INTERVAL 30 DAYS
    GROUP BY date
    ORDER BY date
  `;

  db.all(query, (err, result) => {
    if (err) {
      res.status(500).json({ error: err.message });
    } else {
      res.json(result);
    }
  });
});

// Revenue analytics with Parquet files from S3
app.get('/api/revenue/monthly', (req, res) => {
  const query = `
    SELECT DATE_TRUNC('month', purchase_date) as month,
           SUM(amount) as total_revenue,
           COUNT(*) as transaction_count
    FROM read_parquet('s3://analytics/purchases/*.parquet')
    GROUP BY month
    ORDER BY month DESC
  `;

  db.all(query, (err, result) => {
    if (err) {
      res.status(500).json({ error: err.message });
    } else {
      res.json(result);
    }
  });
});

Python Integration for Data Processing

According to Real Python's guide, DuckDB integrates seamlessly with Python data science workflows:

import duckdb
import pandas as pd

# Create connection to persistent database
conn = duckdb.connect(database="app_analytics.db")

# ETL pipeline: process raw logs into structured data
def process_user_logs():
    query = """
    CREATE TABLE daily_user_metrics AS
    SELECT
        DATE(timestamp) as date,
        user_id,
        COUNT(*) as page_views,
        COUNT(DISTINCT page) as unique_pages,
        MAX(session_duration) as max_session_duration
    FROM read_json_auto('raw_logs/*.json')
    GROUP BY date, user_id
    """
    conn.execute(query)

# Direct Pandas integration for existing workflows
def get_user_cohorts():
    df = conn.sql("""
        SELECT
            DATE_TRUNC('month', first_purchase) as cohort_month,
            COUNT(DISTINCT user_id) as users,
            SUM(total_spent) as revenue
        FROM user_purchases
        GROUP BY cohort_month
        ORDER BY cohort_month
    """).df()

    return df

# Export results for visualization tools
conn.execute("COPY daily_user_metrics TO 'dashboard_data.parquet'")

Configuration for Production Workloads

For production deployments, DuckDB requires specific memory and threading configurations:

-- Configure memory usage (important for containerized environments)
SET memory_limit = '4GB';

-- Optimize for multi-core servers
SET threads = 8;

-- Configure temporary storage for large datasets
SET temp_directory = '/tmp/duckdb';

-- Disable insertion order preservation for better performance
SET preserve_insertion_order = false;

Advanced Usage & Best Practices

Performance Optimization Strategies

DuckDB's performance can be significantly improved through proper query optimization and system configuration. The Performance Guide provides several critical optimization techniques.

Query Profiling and Analysis:

Use EXPLAIN ANALYZE to understand query execution plans and identify bottlenecks:

EXPLAIN ANALYZE
SELECT customer_segment, AVG(purchase_amount)
FROM read_parquet('customer_data.parquet')
WHERE purchase_date >= '2024-01-01'
GROUP BY customer_segment;

Prepared Statements for Repeated Queries:

For web applications with repeated query patterns, prepared statements reduce parsing overhead:

// Node.js prepared statement example
const stmt = db.prepare(`
  SELECT DATE_TRUNC('day', timestamp) as date,
         COUNT(*) as events
  FROM user_events
  WHERE user_id = ? AND timestamp >= ?
  GROUP BY date
`);

app.get('/api/user/:id/activity', (req, res) => {
  const since = req.query.since || '2024-01-01';
  stmt.all(req.params.id, since, (err, result) => {
    res.json(result);
  });
});

Memory Management for Large Datasets:

According to the performance guide, DuckDB can outperform uncompressed in-memory databases by up to 8× when using compressed on-disk storage:

-- Create compressed persistent database
CREATE TABLE large_dataset AS
SELECT * FROM read_parquet('huge_dataset.parquet');

-- Configure spill-to-disk for memory-intensive operations
SET temp_directory = '/fast_ssd/duckdb_temp';

Extension System for Advanced Capabilities

DuckDB's extension system enables additional functionality without bloating the core database. Extensions can be installed and loaded as needed:

-- Install and load spatial extension for geographic data
INSTALL spatial;
LOAD spatial;

-- Query geospatial data with spatial indexes
SELECT city, COUNT(*) as locations
FROM read_csv_auto('store_locations.csv')
WHERE ST_DWithin(
  ST_Point(longitude, latitude),
  ST_Point(-122.4194, 37.7749), -- San Francisco
  10000  -- 10km radius
)
GROUP BY city;

-- Full-text search capabilities
INSTALL full_text_search;
LOAD full_text_search;

CREATE TABLE documents AS
SELECT * FROM read_csv_auto('company_docs.csv');

-- Create full-text index
PRAGMA create_fts_index('documents', 'doc_id', 'title', 'content');

-- Search documents
SELECT doc_id, title, score
FROM (SELECT *, fts_main_documents.match_bm25(doc_id, 'database optimization') AS score
      FROM documents) sq
WHERE score IS NOT NULL
ORDER BY score DESC;

Integration with Modern Data Stack

Apache Arrow Integration:

DuckDB provides zero-copy data exchange with Apache Arrow, enabling high-performance integration with other data processing tools:

import duckdb
import pyarrow as pa

# Query directly returns Arrow table
arrow_table = duckdb.sql("SELECT * FROM read_parquet('data.parquet')").arrow()

# Process with Arrow compute functions
filtered = pa.compute.filter(arrow_table,
                           pa.compute.greater(arrow_table['revenue'], 1000))

Data Lake Connectivity:

Modern data lake formats like Delta Lake and Apache Iceberg are supported through extensions:

INSTALL delta;
LOAD delta;

-- Query Delta Lake tables directly
SELECT transaction_date, SUM(amount) as daily_total
FROM delta_scan('s3://data-lake/transactions/')
WHERE transaction_date >= '2024-01-01'
GROUP BY transaction_date;

Real-World Usage Patterns

ETL Pipeline Replacement

Many full-stack developers use DuckDB to replace complex ETL scripts with simple SQL queries. Instead of writing Python or Node.js code to parse and transform CSV files, you can process them directly:

-- Transform raw e-commerce logs into analytics table
CREATE TABLE daily_sales_metrics AS
SELECT
  DATE(timestamp) as sale_date,
  product_category,
  COUNT(*) as transactions,
  SUM(amount) as revenue,
  AVG(amount) as avg_transaction,
  COUNT(DISTINCT customer_id) as unique_customers
FROM read_csv_auto('raw_sales_logs/*.csv')
WHERE timestamp >= CURRENT_DATE - INTERVAL 90 DAYS
GROUP BY sale_date, product_category;

-- Export for dashboard tools
COPY daily_sales_metrics TO 'dashboard_data.parquet';

Real-time Analytics APIs

DuckDB excels at powering analytics APIs that need to process large datasets quickly:

// Express.js API for real-time business metrics
app.get('/api/metrics/conversion-funnel', async (req, res) => {
  const { start_date, end_date } = req.query;

  const query = `
    WITH funnel_steps AS (
      SELECT
        user_id,
        MAX(CASE WHEN event_type = 'page_view' THEN 1 ELSE 0 END) as viewed,
        MAX(CASE WHEN event_type = 'add_to_cart' THEN 1 ELSE 0 END) as added_cart,
        MAX(CASE WHEN event_type = 'checkout' THEN 1 ELSE 0 END) as checked_out,
        MAX(CASE WHEN event_type = 'purchase' THEN 1 ELSE 0 END) as purchased
      FROM read_parquet('user_events/*.parquet')
      WHERE date BETWEEN ? AND ?
      GROUP BY user_id
    )
    SELECT
      SUM(viewed) as page_views,
      SUM(added_cart) as cart_additions,
      SUM(checked_out) as checkouts,
      SUM(purchased) as purchases,
      ROUND(100.0 * SUM(added_cart) / SUM(viewed), 2) as view_to_cart_rate,
      ROUND(100.0 * SUM(purchased) / SUM(viewed), 2) as overall_conversion_rate
    FROM funnel_steps
  `;

  try {
    db.all(query, [start_date, end_date], (err, result) => {
      if (err) throw err;
      res.json(result[0]);
    });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

Data Science Workflow Integration

DuckDB fits naturally into data science workflows, providing SQL interface to large datasets without requiring complex infrastructure:

import duckdb
import matplotlib.pyplot as plt

def analyze_user_retention():
    conn = duckdb.connect()

    # Complex retention analysis with window functions
    retention_data = conn.sql("""
        WITH user_activity AS (
          SELECT
            user_id,
            DATE_TRUNC('week', event_date) as week,
            MIN(event_date) OVER (PARTITION BY user_id) as first_active_week
          FROM read_parquet('user_events.parquet')
        ),
        weekly_cohorts AS (
          SELECT
            first_active_week as cohort_week,
            week,
            EXTRACT(WEEK FROM week) - EXTRACT(WEEK FROM first_active_week) as week_number,
            COUNT(DISTINCT user_id) as active_users
          FROM user_activity
          GROUP BY cohort_week, week
        )
        SELECT
          cohort_week,
          week_number,
          active_users,
          100.0 * active_users / FIRST_VALUE(active_users) OVER (
            PARTITION BY cohort_week ORDER BY week_number
          ) as retention_percentage
        FROM weekly_cohorts
        ORDER BY cohort_week, week_number
    """).df()

    return retention_data

# Use results with existing data science tools
retention_df = analyze_user_retention()
retention_pivot = retention_df.pivot(index='cohort_week',
                                   columns='week_number',
                                   values='retention_percentage')

Comparison with Alternatives

Understanding when to choose DuckDB over alternatives requires examining specific use case requirements and performance characteristics.

DuckDB vs PostgreSQL

According to Airbyte's analysis, DuckDB demonstrates 3-5x faster performance than PostgreSQL for single-node analytical workloads, particularly excelling in aggregations and data transformations.

When to Choose DuckDB:

Embedded analytics within applications
Data processing pipelines with primarily read-heavy workloads
Rapid prototyping and development environments
Applications processing datasets up to several hundred GB

When to Choose PostgreSQL:

Multi-user transactional applications
Applications requiring ACID compliance for writes
Complex applications needing stored procedures, triggers, and advanced SQL features
Production systems requiring high availability and replication

DuckDB vs SQLite

According to BetterStack's comparison, SQLite is optimized for OLTP workloads while DuckDB specializes in OLAP and complex queries over large datasets.

Performance Characteristics:

SQLite: Superior for small, frequent transactions and simple queries
DuckDB: Superior for analytical queries, aggregations, and processing large datasets

Deployment Considerations:

Both databases are embedded and require no server management, making them suitable for similar deployment scenarios but with different optimization focuses.

DuckDB vs ClickHouse

Scalability Differences:

ClickHouse: Designed for petabyte-scale distributed analytics across multiple servers
DuckDB: Optimized for single-node analytics up to multi-terabyte datasets

Operational Complexity:

ClickHouse: Requires cluster management, distributed system expertise
DuckDB: Zero configuration, embedded deployment

When to Choose ClickHouse:

Datasets exceeding several terabytes
Multi-datacenter analytics requirements
Teams with distributed systems expertise

Performance Validation

According to KDNuggets' benchmark, DuckDB consistently achieved the fastest query execution times compared to SQLite and Pandas on standardized 1 million row datasets, particularly for GROUP BY operations and complex aggregations.

Limitations & Considerations

Understanding DuckDB's limitations is crucial for making informed architectural decisions in production environments.

Memory Management Challenges

DuckDB experiences frequent memory-related production issues that require careful planning. According to troubleshooting docs, out-of-memory errors commonly manifest as OutOfMemoryException, and on Linux systems, the OOM reaper may kill the DuckDB process entirely.

Critical memory configurations include:

Explicit Memory Limits: SET memory_limit = '8GB'; prevents unbounded memory usage
Memory Optimization: SET preserve_insertion_order = false; reduces memory footprint
Disk Spilling: SET temp_directory = '/fast_ssd/tmp'; enables spill-to-disk
Thread Management: SET threads = 4; reduces thread count to limit memory usage

Production applications must implement monitoring for OOM conditions and automatic process restart capabilities, as memory errors can cause complete application failure.

Concurrency Architecture Constraints

According to concurrency docs, the database supports multiple concurrent reads and writes within a single process, but only when there are no write conflicts. The system employs optimistic concurrency control where transactions attempting to modify the same rows simultaneously result in transaction conflict errors.

Key limitations include:

Single Process Writes: Only one process can have a write connection to a database file at a time
Multi-Process Coordination: Multi-process writes require application-level design patterns like cross-process mutex locks or connection retry logic
No Connection Pooling: No built-in connection pooling across processes

For web applications with multiple worker processes, this creates architectural constraints requiring careful database access coordination or accepting single-process deployment limitations.

Data Size and Performance Constraints

According to operations manual, the database enforces several critical constraints:

4GB limit for BLOB and String data types
Large database connections (15TB+) may require several seconds for initialization
Checkpoint operations become progressively slower, impacting application startup performance

Stability and Production Readiness

Memory corruption issues have been documented in production environments. GitHub issue #8230 reports memory corruption occurring when using httpfs with views referencing parquet files. Additional concurrency bugs documented in GitHub issue #243 show concurrent writes failing on first write operations to new catalogs.

Deployment Architecture Limitations

DuckDB's embedded, single-node architecture prevents horizontal scaling and creates inherent single points of failure:

No built-in high availability or failover mechanisms
No read replica capabilities
Cannot distribute queries across multiple machines
Limited by single-machine CPU and memory resources

FAQ

Q: Can DuckDB replace PostgreSQL for my web application database?

A: DuckDB complements rather than replaces PostgreSQL. Use PostgreSQL for transactional operations (user management, orders, content management) and DuckDB for analytical queries (dashboards, reports, data processing). DuckDB's single-writer concurrency model makes it unsuitable for high-concurrency transactional workloads.

Q: How does DuckDB handle datasets larger than available RAM?

A: DuckDB intelligently manages memory through spill-to-disk mechanisms and memory-mapped files. Configure SET temp_directory = '/path/to/fast/storage' and SET memory_limit = 'XGB' to enable out-of-core processing. However, queries with multiple blocking operations (GROUP BY, JOIN, ORDER BY) may still encounter out-of-memory errors.

Q: What's the maximum database size DuckDB can handle?

A: DuckDB can theoretically handle databases up to several terabytes on a single machine. However, connection initialization for very large databases (15TB+) may take several seconds, and checkpoint operations become progressively slower, impacting application startup performance.

Q: Can I use DuckDB in a containerized microservices architecture?

A: Yes, but with careful memory configuration. Set explicit memory limits (SET memory_limit) that account for container constraints, and ensure containers have sufficient memory allocation for peak analytical workloads. Consider using persistent volumes for database files and temporary storage.

Q: How do I handle concurrent access from multiple application instances?

A: DuckDB allows only one process to have write access to a database file. For multi-instance deployments, consider: using separate read-only replicas, implementing application-level write coordination, or using DuckDB for read-only analytics while maintaining writes in another system.

Q: What happens if DuckDB runs out of memory during a query?

A: The process may terminate with an OutOfMemoryException or be killed by the system's OOM killer. Implement application-level monitoring for memory usage and automatic process restart capabilities. Configure preserve_insertion_order = false and appropriate memory limits to prevent OOM conditions.

Q: Can DuckDB query data directly from S3 or other cloud storage?

A: Yes, through extensions like httpfs and aws. Use queries like SELECT * FROM read_parquet('s3://bucket/data.parquet') after loading the appropriate extension. Authentication uses standard AWS SDK credentials or explicit configuration.

Q: How does DuckDB's SQL compatibility compare to PostgreSQL?

A: DuckDB supports standard SQL with many PostgreSQL-compatible functions and syntax. However, it lacks stored procedures, triggers, and some advanced PostgreSQL features. Check the SQL documentation for specific compatibility details.

Q: Should I use DuckDB for real-time analytics in production?

A: DuckDB excels at near-real-time analytics (seconds to minutes latency) but isn't designed for sub-second real-time requirements. It's ideal for dashboard queries, periodic reports, and batch processing workflows rather than millisecond-latency operational analytics.

Q: What's the best way to integrate DuckDB with existing data pipelines?

A: DuckDB integrates well as a processing engine within existing pipelines. Use it to replace complex ETL scripts with SQL queries, process files directly from cloud storage, and export results to formats compatible with downstream systems (Parquet, CSV, Arrow).

The Embedded Analytics Sweet Spot

DuckDB represents a significant evolution in embedded database technology, specifically addressing the analytical workload gap that traditional embedded databases like SQLite couldn't fill effectively. For full-stack developers building data-intensive applications, DuckDB offers a compelling combination of SQL familiarity, zero-configuration deployment, and exceptional analytical performance.

The database shines in scenarios where you need fast analytical capabilities embedded within applications: processing user behavior data for dashboards, running complex aggregations for reports, or transforming large datasets without managing separate data infrastructure. Its ability to query files directly from cloud storage and integrate seamlessly with modern data science tools makes it particularly valuable for teams building data-driven features.

However, DuckDB's limitations around memory management, concurrency constraints, and single-node architecture require careful consideration in production environments. It's best viewed as a specialized tool that complements rather than replaces your existing database infrastructure.

For teams evaluating DuckDB, start with non-critical analytical workloads to understand its performance characteristics and operational requirements. The combination of its embedded nature, exceptional analytical performance, and comprehensive file format support makes it a valuable addition to the modern developer's toolkit as applications increasingly need to process and analyze large volumes of data efficiently.