Announcing BigInt columns: Store 64-bit integers for counters, IDs, and timestamps_

A 32-bit signed integer caps out at roughly -2.1 billion on the low end and +2.1 billion on the high end. The moment your column needs to hold a value outside that range, in either direction, the existing integer type stops being enough.

To close this gap, we’re introducing BigInt columns in Appwrite Databases.

BigInt is a new column type that stores 64-bit signed integers natively, with the same min, max, and default parameters you already use with regular integer columns. Previously, the only way to store 64-bit values was to set size: 8 on an integer column, which was easy to miss and felt out of place on a type called integer. BigInt makes the intent explicit: if your data fits in a 32-bit integer, you don’t need to change anything; if it doesn’t, BigInt is the column type you reach for.

What BigInt gives you

A BigInt column accepts any value in the 64-bit signed integer range, from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. That’s roughly 4 billion times the range of a 32-bit integer column, and enough to cover the data types where 32-bit was always the wrong size:

• Large counters and accumulators: lifetime views, total bytes processed, cumulative API calls, retry counters that keep climbing across years of operation.
• External IDs: account IDs, message IDs, or transaction IDs imported from systems that use 64-bit keys.
• High-resolution timestamps: nanosecond or microsecond epochs, monotonic clocks, sequence numbers from event logs.
• Financial values in minor units: balances, totals, or ledger entries stored as integers in the smallest currency unit, where you want to avoid floating-point rounding entirely.

Works with Operators

BigInt columns plug straight into Operators, so you can update a 64-bit value directly on the server without fetching the row first. Operator.increment, Operator.decrement, and the rest of the numeric operators treat BigInt the same way they treat integer and float columns: the change is applied atomically under concurrency control, respects any min or max bounds you set, and returns the new value.

This means a counter like total_views can sit at 12 billion, get hammered with concurrent +1 requests across regions, and stay consistent without any client-side coordination.

Creating a BigInt column

You can create a BigInt column from the Appwrite Console or programmatically using any of the Server SDKs.

From the Console

In the Appwrite Console, open your table, head to the Columns tab, and click Create column. Pick BigInt from the type dropdown, give it a key, and optionally set min, max, and default. The column is ready to read and write the moment the request returns.

From a Server SDK

Appwrite Server SDKs require an API key with tables.write (or collections.write for the legacy API).

When to use BigInt over integer

The simple rule: if the values your column holds will always fit in 32-bit signed range (-2,147,483,648 to 2,147,483,647), stick with integer. It’s a smaller type, slightly cheaper to store, and matches the most common case.

Reach for BigInt when any of the following is true:

• You expect values larger than ~2.1 billion at any point in the column’s lifetime.
• You’re importing IDs from a system that already uses 64-bit keys.
• The column stores cumulative metrics that grow unbounded over time.
• You want headroom for a counter that might run for years across many users.

There is no automatic migration between integer and BigInt, so picking the right type up front saves you a schema change later. If you’re unsure, BigInt is a safe default for any counter, ID, or timestamp where the upper bound isn’t obvious.

Get started

BigInt columns are available on Appwrite Cloud today.

You can create your first BigInt column directly from the Console, or roll it out programmatically through any of the Server SDKs above. The new column type works with every TablesDB feature you already use, including Operators, indexes, and full schema creation.

More resources