Skip to content

Update dependency questdb to v4#137

Merged
CM000n merged 1 commit intomainfrom
renovate/questdb-4.x
Nov 28, 2025
Merged

Update dependency questdb to v4#137
CM000n merged 1 commit intomainfrom
renovate/questdb-4.x

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate Bot commented Oct 18, 2025

This PR contains the following updates:

Package Change Age Confidence
questdb (changelog) ^3.0.0 -> ^4.0.0 age confidence

Release Notes

questdb/py-questdb-client (questdb)

v4.1.0

Compare Source

Features


Decimal Data Type Support
*************************

This release adds support for ingesting data into QuestDB's native
``DECIMAL(precision, scale)`` column type introduced in QuestDB 9.2.0.
Use decimals when you need exact-precision values (e.g. prices, balances)
without floating-point rounding issues.

Decimal values can be sent using Python ``decimal.Decimal`` objects in both
``row()`` and ``dataframe()`` methods. When sending dataframes, you can also use
PyArrow decimal types for better performance.

Sending decimals requires protocol version 3. When using HTTP, this protocol
version is auto-negotiated. For TCP connections, you must explicitly specify
``protocol_version=3`` in the configuration string:

.. code-block:: python

### HTTP - protocol version 3 is auto-negotiated
    conf = 'http::addr=localhost:9000;'

### TCP - must specify protocol_version=3 explicitly
    conf = 'tcp::addr=localhost:9009;protocol_version=3;'

.. important::
    **Server Requirement**: This feature requires QuestDB server version 9.2.0 or higher.
    
    Unlike other column types, DECIMAL columns **must be created in advance** via SQL
    before ingesting data. Auto-creation is not supported for DECIMAL columns.
    
    For details on creating DECIMAL columns and working with this data type, see the
    `QuestDB Decimal documentation <https://questdb.com/docs/concept/decimal/>`_.

**Usage with Python Decimal objects:**

.. code-block:: python

    from decimal import Decimal
    from questdb.ingress import Sender, TimestampNanos

### First, create the table with DECIMAL column via SQL:
### CREATE TABLE trades (

###     symbol SYMBOL,
###     price DECIMAL(18,4),

###     amount DECIMAL(18,8),
###     timestamp TIMESTAMP

### ) TIMESTAMP(timestamp);
    
    conf = 'http::addr=localhost:9000;'
    with Sender.from_conf(conf) as sender:
        sender.row(
            'trades',
            symbols={'symbol': 'ETH-USD'},
            columns={
                'price': Decimal('2615.5400'),
                'amount': Decimal('0.00044000')},
            at=TimestampNanos.now())

**Usage with Python Decimal objects in Pandas dataframes:**

.. code-block:: python

    import pandas as pd
    from decimal import Decimal

### Create DataFrame with Python Decimal objects
    df = pd.DataFrame({
        'symbol': ['ETH-USD', 'BTC-USD'],
        'price': [Decimal('2615.5400'), Decimal('43210.1234')],
        'volume': [Decimal('1234.56789012'), Decimal('98.76543210')]
    })
    
    with Sender.from_conf(conf) as sender:
        sender.dataframe(
            df, 
            table_name='trades',
            symbols='symbol',
            at=TimestampNanos.now())

**Usage with PyArrow Decimal types in Pandas dataframes:**

.. code-block:: python

    import pandas as pd
    import pyarrow as pa
    from decimal import Decimal

### Create DataFrame with Arrow decimal types
    df = pd.DataFrame({
        'prices': pd.array(
            [Decimal('-99999.99'), Decimal('-678.00')],
            dtype=pd.ArrowDtype(pa.decimal128(18, 2))
        )
    })
    
    with Sender.from_conf(conf) as sender:
        sender.dataframe(df, table_name='prices', at=TimestampNanos.now())

Additional Arrow Data Type Support
**********************************

Added support for additional PyArrow column types commonly encountered when
deserializing from Parquet files or converting Polars dataframes to Pandas:

* ``int16``, ``int32``, ``float32`` (float), ``bool``
* ``string``, ``large_string`` (including as symbol types)
* ``timestamp[us]`` with timezone support for microsecond-precision timestamps

Microsecond Timestamp Precision
*******************************

Microsecond-precision timestamp columns (``datetime64[us]`` in NumPy and
``timestamp[us]`` in PyArrow) are now fully supported. When using
``protocol_version`` 2 or higher, microsecond timestamps are sent with full
precision, including for the designated timestamp column.

Bug fixes
  • Updated type hints to allow None as a valid column value in
    Sender.row(). This brings the type annotations in line with the actual
    behavior, where None values have always been supported to represent NULL
    values.

Python Version Support


* Added support for Python 3.14 on all platforms and 3.14t (free threaded) on
  all platforms except Windows.
* Dropped support for Python 3.9 (end of life).

4.0.0 (2025-10-17)
------------------

New Breaking Change Feature

From QuestDB 9.1.0 onwards you can use CREATE TABLE SQL statements with
TIMESTAMP_NS column types, or rely on column auto-creation.

This client release adds support for sending nanoseconds timestamps to the
server without loss of precision.

This release does not introduce new APIs, instead enhancing the sender/buffer's
.row() API to additionally accept nanosecond precision.

.. code-block:: python

conf = 'http::addr=localhost:9000;'

or conf = 'tcp::addr=localhost:9009;protocol_version=2;'

with Sender.from_conf(conf) as sender:
    sender.row(
        'trade_executions',
        symbols={
            'product': 'VOD.L',
            'parent_order': '65d1ba36-390e-49a2-93e3-a05ef004b5ff'
            'side': 'buy'},
        columns={
            'order_sent': TimestampNanos(1759246702031355012)},
        at=TimestampNanos(1759246702909423071))

If you're using dataframes, nanosecond timestamps are now also transferred with
full precision.

The change is backwards compatible with older QuestDB releases which will simply
continue using the TIMESTAMP column, even when nanoseconds are specified in
the client.

This is a breaking change because it introduces new breaking timestamp
column auto-creation <https://questdb.com/docs/reference/api/ilp/overview/#table-and-column-auto-creation>
behaviour. For full details and upgrade advice, see the
nanosecond PR on GitHub <https://github.com/questdb/py-questdb-client/pull/113>_.

v4.0.0: 4.0.0

Compare Source

New Breaking Change Feature

From QuestDB 9.1.0 onwards you can use CREATE TABLE SQL statements with
TIMESTAMP_NS column types, or rely on column auto-creation.

This client release adds support for sending nanoseconds timestamps to the
server without loss of precision.

This release does not introduce new APIs, instead enhancing the sender/buffer's
.row() API to additionally accept nanosecond precision.

conf = 'http::addr=localhost:9000;'

# or `conf = 'tcp::addr=localhost:9009;protocol_version=2;'`
with Sender.from_conf(conf) as sender:
    sender.row(
        'trade_executions',
        symbols={
            'product': 'VOD.L',
            'parent_order': '65d1ba36-390e-49a2-93e3-a05ef004b5ff'
            'side': 'buy'},
        columns={
            'order_sent': TimestampNanos(1759246702031355012)},
        at=TimestampNanos(1759246702909423071))

If you're using dataframes, nanosecond timestamps are now also transferred with
full precision.

The change is backwards compatible with older QuestDB releases which will simply
continue using the TIMESTAMP column, even when nanoseconds are specified in
the client.

This is a breaking change because it introduces new breaking timestamp column auto-creation behaviour. For full details and upgrade advice, see the nanosecond PR on GitHub.

Full Changelog: questdb/py-questdb-client@v3.0.0...v4.0.0


Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot force-pushed the renovate/questdb-4.x branch from 9ae2614 to c7e2923 Compare November 28, 2025 20:32
@CM000n CM000n merged commit b87ad61 into main Nov 28, 2025
10 checks passed
@CM000n CM000n deleted the renovate/questdb-4.x branch November 28, 2025 22:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant