Product DocumentationDisk Quotas
The disk quota feature allows users to limit disk usage for individual databases, tables, and schemas based on quotas. This feature can be implemented to separate use cases and users in terms of disk usage and prevent the accidental consumption of too much space, which could cause serious issues for user applications. In the event of trying to consume more space than allowed by the quota, the transaction is aborted and rolled back when the limit is met.
For example, Database A has a quota of 10TB. If a transaction that would otherwise consume 15TB is run on Database A, it would be stopped and rolled back once it meets the limit.
It is important to note that the quota is not an amount of reserved usage for a given object but rather an upper bound on the given object's disk usage. This means that the total of database quotas can be higher or lower than the total available disk space, and the total of table and schema quotas can be higher or lower than the database quota or the total available space.
For example, Databases A, B, and C have a total of 100TB of disk space. Database A has a quota of 10TB, and Databases B and C have no quotas set. If Database A uses 2TB of data, then Databases B and C can use all remaining 98TB of space.
Disk Quota Behavior
When set, disk quotas apply to all data created, including data that is not yet committed. The disk quota is checked whenever a user query creates data. If a query creates more data than is allocated for the object, an error is thrown, and the transaction that hits the limit is rolled back. When a quota is set, it only affects the given object: the database, schema, or table.
If quotas are set at multiple levels of the database > schema > table hierarchy, whichever quota is set the lowest takes precedence. You can set a smaller quota on a schema than on a table inside that schema, for example. The total of one level of the hierarchy does not need to add up to the next level and can be higher or lower.
Note: Disk quotas must take into account any storage that is being consumed by the row store. When write operations send rows to the row store, and they have not yet been flushed to the column store (or "garbage-collected" in the case of deleted rows), these rows count toward the disk quota. For example, if you set your database quota to 770GB, and 765GB is already being used, a delete of 4GB would put you within 1GB of reaching the quota limit, and you could exceed the limit on the next INSERT or DELETE that targets a table in the same database.
DELETE and TRUNCATE operations can always be run on objects with a quota, and DROP is allowed on objects in schemas with quotas.
You can query the following system views to monitor disk quota-related behavior:
Setting and Disabling Disk Quotas
By default, no limits are set on disk usage, which is not impacted by installations and upgrades. Using an ALTER DATABASE, ALTER TABLE, or ALTER SCHEMA command, you can set or disable the maximum amount of space for an individual database, schema, or table, respectively. Quotas on objects can be set by superusers and the owner of the object. Changing a disk quota does not require restarting the database, and the changes should apply as soon as the transaction reads the quota value from the database.
Note: The system has a default maximum of 500k disk usage objects. You can change the maximum to a value from 100 to 20000000 using an ALTER SYSTEM command. For example, if you wanted to increase the maximum from 500k objects to 1000000:
yellowbrick=# alter system set max_quota_objects to 1000000;
WARNING: Will be effective after the next server configuration reload, or after the next server restart in the case of parameters that can only be changed at server start
ALTER SYSTEMParent topic:Managing Tables and Views