v21では，プロセス名が$記号から始まる場合，ローカルプロセスと呼ばれる特殊な振る舞いをする仕組みが廃止されました。これは仕様の変更です。
v12以前のバージョンでは，ローカルおよびグローバルプロセスの間に明確な区別がありました。
ローカルプロセスは、データアクセスを必要としない処理の場合にだけ使用することをお勧めします。例えば、イベント処理メソッドを実行、またはフローティングウィンドウ等のインタフェース要素を制御するためにローカルプロセスを使用します。
名前によってプロセスがローカルであることを指定します。ローカルプロセス名は、先頭にドル記号 ($) を付ける必要があります。
グローバルプロセスには，クライアント側のカレントレコード・命名セレクション・セット・トランザクションをサーバー側のトリガプロセス（「サーバー上で実行」メソッドを実行するプロセス）と同期する仕組みがあります。また，データベースにアクセスすることができます。
4D Server: データアクセスを行わない処理に対し、クライアント側でローカルプロセスを使用すると、サーバの負荷が軽減されます。
当時のドキュメントで言及されているように，プロセスからレコードにアクセスする必要がない場合，グローバルプロセスの代わりにローカルプロセスを起動することで，ネットワーク通信とサーバーリソースの最適化を図ることができました。
ローカルプロセスは，直接データベースにアクセスすることができません。そこでアプリケーションプロセス（プロセス番号1）のデータベースコンテキストを「借りて」サーバーと通信する仕組みが用意されていました。便利な仕組みではありますが，危険なことでもありました。
警告: ローカルプロセスでデータアクセスを行った場合、メインプロセスでアクセスすることになり、そのプロセス内で実行される処理との間でコンフリクトが起きるおそれがあります。
ドキュメントの警告を無視し，アプリケーションプロセスとローカルプロセスの両方からデータベースにアクセスすると，サーバーがクラッシュする恐れがあります。こうした問題を避けるため，v21ではプロセス名が$記号から始まるローカルプロセスの概念そのものが廃止されました。
v13以降，グローバルプロセスは，クライアント側で起動し，初回のレコードアクセスでデータベースコンテキストが作成されるように改良されています。つまり，ローカルプロセスからグローバルプロセスに「昇格」します。言い換えるなら，データベースにアクセスしない限り，グローバルプロセスは従来のローカルプロセスと何も変わりません。誤ってアプリケーションプロセスとローカルプロセスの両方からデータベースにアクセスするリスクを抱えることなく，安全にネットワーク通信とサーバーリソースの最適化を図ることができます。
4Dのフィールドタイプ「UUID」は，GUIとランゲージにおいて文字列のように扱われますが，内部的には128ビット整数であり，データベースエンジンの検索も文字列ではなく整数値に対して実行されます。キャッシュに格納されるのも32文字の16進数（64バイト）ではなく，128ビットの整数（16バイト）です。
UUIDプライマリーキーのインデックス検索は最適化されており，まず，前半の64ビット値に対して検索が実行され，複数のレコードがヒットした場合には，後半の64ビット値に対して絞り込み検索が実行されます。UUIDの特性により，ほとんど場合，前半の検索だけで1件のレコードが特定されるため，UUIDプライマリーキーの検索速度は，実質的に64ビット整数型のプライマリーキーと遜色ありません。