Project: YugabyteDB (App Definition and Development / Database)
File: best-practices-ysql.md

title: Best practices for YSQL applications headerTitle: Best practices linkTitle: Best practices description: Tips and tricks to build YSQL applications headcontent: Tips and tricks to build YSQL applications for high performance and availability menu: v2.18: identifier: best-practices-ysql parent: develop weight: 570 type: docs {{<api-tabs>}} Running applications in multiple data centers with data split across them is not a trivial task. When designing global applications, choose a suitable design pattern for your application from a suite of battle-tested design paradigms, including , , , , and more. You can also combine these patterns as per your needs. {{<tip>}} For more details, see . {{</tip>}} When a query uses an index to look up rows faster, the columns that are not present in the index are fetched from the original table. This results in additional round trips to the main table leading to increased latency. Use to store all the required columns needed for your queries in the index. Indexing converts a standard Index-Scan to an . {{<tip>}} For more details, see . {{</tip>}} If you need values in some of the columns to be unique, you can specify your index as `UNIQUE`. When a unique index is applied to two or more columns, the combined values in these columns can't be duplicated in multiple rows. Note that because a NULL value is treated as a distinct value, you can have multiple NULL values in a column with a unique index. {{<tip>}} For more details, see . {{</tip>}} Sequences in databases automatically generate incrementing numbers, perfect for generating unique values like order numbers, user IDs, check numbers, and so on. They prevent multiple application instances from concurrently generating duplicate values. However, generating sequences on a database that is spread across regions could have a latency impact on your applications. Enable to improve the speed of sequences, and also avoid discarding many sequence values when an application disconnects. {{<tip>}} For a demo, see the YugabyteDB Friday Tech Talk on . {{</tip>}} Common scenarios of updating rows and fetching the results in multiple statements can lead to multiple round-trips between the application and

In many cases, rewriting these statements as single statements using the `RETURNING` clause will lead to lower latencies as YugabyteDB has optimizations to make single statements faster. For example, the following statements: ```sql SELECT v FROM txndemo WHERE k=1 FOR UPDATE; UPDATE txndemo SET v = v + 3 WHERE k=1; SELECT v FROM txndemo WHERE k=1; ``` can be re-written as follows: ```sql UPDATE txndemo SET v = v + 3 WHERE k=1 RETURNING v; ``` {{<tip>}} For more details, see . {{</tip>}} Use to split your data into multiple partitions according to date so that you can quickly delete older data by dropping the partition. {{<tip>}} For more details, see . {{</tip>}} YugabyteDB provide advanced cluster-aware load-balancing capabilities that enables your applications to send requests to multiple nodes in the cluster just by connecting to one node. You can also set a fallback hierarchy by assigning priority to specific regions and ensuring that connections are made to the region with the highest priority, and then fall back to the region with the next priority in case the high-priority region fails. {{<tip>}} For more details, see . {{</tip>}} Set up different pools with different load balancing policies as needed for your application to scale by using popular pooling solutions such as HikariCP and Tomcat along with YugabyteDB . {{<tip>}} For more details, see . {{</tip>}} Whenever possible, use to ensure that YugabyteDB can re-use the same query plan and eliminate the need for a server to parse the query on each operation. {{<tip>}} For more details, see . {{</tip>}} Use `BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE READ ONLY DEFERRABLE` for batch or long-running jobs, which need a consistent snapshot of the database without interfering, or being interfered with by other transactions. {{<tip>}} For more details, see . {{</tip>}} For large or batch `SELECT`s or `DELETE`s that have to scan all tablets, you can parallelize your operation by creating queries that affect only a specific part of the tablet using the `ybhashcode` function. {{<tip>}} For more details, see . {{</tip>}} deletes the database files that store the table data and is much faster than , which inserts a delete marker for each row in transactions that are later removed from storage during compaction runs. {{<warning>}} Currently, TRUNCATE is not transactional. Also, similar to PostgreSQL, TRUNCATE is not MVCC-safe. For more details, see . {{</warning>}}