Tworząc transakcje, oprócz bazy, można podać listę obiektów w bazie, które mają być zarezerwowane na potrzeby danej transakcji. Indexed Database API pozwala wykonywać żądania kierowane do siebie w sposób synchroniczny i asynchroniczny. W tym drugim przypadku powiadomienia o zmianie statusu są przekazywane za pomocą zdarzeń.

Projektując to API zwrócono też pewną uwagę na ochronę informacji użytkowników. Przykładowo, można by śledzić aktywność użytkownika, jeżeli dany skrypt sprawdzający występowanie w repozytorium swojego unikalnego obiektu byłby umieszczony na kilku witrynach. Podjęto kroki, które mają przeciwdziałać tego typu scenariuszom. Po pierwsze, można ograniczyć dostęp od repozytorium dla skryptów umieszczonych na głównym poziomie strony. Po drugie, czas życia danego rekordu w repozytorium będzie wygasał. Oprócz tego, wszystkie ograniczenia, jakie użytkownik stosuje wobec "ciasteczek" będą domyślnie przekładać się na rekordy Database API. Dodatkowo, użytkownik będzie mógł jawnie autoryzować dostęp do omawianej funkcjonalności dla wybranych stron czy też definiować widok repozytorium, jaki będzie dostępny dla określonych witryn czy też tworzyć tzn. czarne listy witryn. Pełne zabezpieczenie tej funkcjonalności jest, rzecz jasna, niemożliwe, a podstawowym zagrożeniem jest ryzyko odczytania lub zapisywania danych użytkownika przez złośliwe skrypty.

Potencjalne zastosowania

Wysiłki podejmowane przez Web Applications Working Group organizacji W3C zmierzają w kierunku wzbogacenia tego, co oferują rozwiązania internetowe. Podstawową możliwością, jaka pojawia się przed programistami oraz użytkownikami dzięki Database API, jest dostęp do pewnych funkcjonalności, nawet kiedy aplikacja pracuje w trybie offline.

Baza danych w przeglądarce wydaje się być rozwiązaniem ryzykownym i zwiększa wrażliwość aplikacji na atak. Jest to jednak na tyle intrygujące, że Google Chrome 4 zawiera wsparcie dla Web SQL Database i trzeba się spodziewać, że wraz z kresem prac nad Web SQL Database i popularyzacją Database API przeglądarki zaczną implementować właśnie ten nowszy standard. Wskazywać na to mogą pierwsze opinie opublikowane przez Pablo Castro, architekta w grupie Microsoft SQL Server. "Jest to dobry kandydat dla niezależnych, interoperacyjnych implementacji" - zaznacza Pablo Castro i jednocześnie podkreśla, że będą toczyć się prace nad rozpoznaniem mocnych i słabych stron tego standardu. Wobec tego, wydaje się, że nawet tak kontrowersyjny pomysł i związane z nim potencjalne zagrożenia nie są w stanie zahamować trendu, w którym coraz więcej składników rozwiązań jest implementowanych po stronie klienta.