4Dのコンパイラーは，64ビット整数をサポートしていません。SQLはコンパイルの対象外であるため，例外的に64ビット整数型フィールドが扱えます。64ビット整数型のコンパイルをサポートするためには，コンパイラーの全面的な書き換えが必要となり，これには２ないし５年の歳月がかかると想定されています。現時点で64ビット整数型のサポートは計画されていません。
バリアント型やオブジェクト型は，マクロ（プリプロセッサ）によって展開される擬似的なデータ型なので，コンパイラーを全面的に書き換えることなく，比較的短期間でランゲージに追加することができました。オブジェクト記法も同様です。
PostgreSQLなど，64ビット整数型のプライマリーキーを使用するような外部システムと連携する場合，32ビット整数型のフィールドでは同期ができない，という問題に直面します。プライマリーキーは，基本的にシーケンス番号であり，実際に64ビット整数の最大値（符号付きで9,223,372,036,854,775,807=922京3372兆368億5477万5807）まで使用することはないとはいえ，32ビット整数の最大値（2,147,483,647=21億4748万3647）では足りなくなる恐れがあります。
そのようなわけで，19r6では，実数型を53ビット整数として使用できるようになりました。
Support of larger integers than integer32
4Dの実数型はIEEE 754準拠の倍精度浮動小数点数であり，符号1・仮数52・指数11の64ビット（8バイト）で成り立っています。53ビットあれば，MAX_SAFE_INTEGERつまり9,007,199,254,740,991=9007兆1992億5474万991までの整数を安全に，つまり誤差を生じさせることなく，加算や現在ができます。
これまでのバージョンでは，おおきな実数を文字列に変換すると12桁の指数表現になり，整数であれば精度が失われました。19r6では，IEEE 754に変換しても精度が失われない整数（15から17桁）を収めた実数は，整数のまま文字列に変換されるよう仕様が見直されています。JSON・XMLドキュメントの実数⇆文字列変換は，整数は整数のまま出力されるようになりました。そのような整数をメソッドエディターに入力した場合，指数表現には変換されず，整数は整数のままトークナイズされるようになりました。